Item9184: Error code 401 now breaks apache login

Someone has recently on trunk changed the error codes returned when you login.

Result is that us running Apache login and not Template are always redirected to the UserRegistration. Even configure returns 401 now.

This does not work with the apache config we specify for apache login

It has a ErrorDocument 401 /trunk/bin/view/System/UserRegistration

Without the redirect to UserRegistration the user is in an endless authentication loop when he tries to login without being registered.

It seems someone changed this vital part of Foswiki without testing it at all in apache login configuration.

Please revert to 200 or a non 401 code.

Release blocker.

-- KennethLavrsen - 22 Jun 2010

AFAICT a 401 is only ever sent in two circumstances:

1. A REST script which requires an authenticated user is invoked, but there is no authenticated user on the authenticated user is not permitted to access the resource.
2. username and password parameters are sent with a request, but they are not valid.

Which of these two are you hitting?

-- CrawfordCurrie - 22 Jun 2010

None of them. The situation is the most basic common use of Foswiki. Nothing special. No rest.

Case 1

• I am not authenticated yet.
• I click on Edit or I click on Login
• I am immediately redirected to UserRegistration

Case 2

• I am not authenticated yet
• I click on the login at the top of the left bar.
• I am immediately redirected to UserRegistration

Case 3

• I try to run configure
• I am immidiately redirected to UserRegistration

Before the change the redirect to 401 came when you put a wrong set of credentials several times (some browser) and when you clicked Cancel. Now it comes right away. That is what goofs it up. I am never allowed to login.

You need to setup your Foswiki for apache login to see this and test a fix. It is easy. All you need to do is add a small section to the apache config and one setting in configure. I change back and forth all the time.

The ApacheConfigGenerator shows how to.

Also note that removing the ErrorDocument 401 is not a fix. If you do this the user is never redirected to the UserRegistration if he cancels out of the login pop-up. We cannot loose this important usability detail for Apache login. Users need to be told how to register when they have no access.

An extra note - the 3 times timeout I talked about on IRC is something I must have seen in IE. Firefox keep on trying until you press Cancel. So look for the behaviour when you click Cancel.

The correct behavior is that pressing Cancel in the browser pop-up login window redirects you to a custom chosen 401 page. This can be a Foswiki page or something else. It cannot be hardcoded. If you use this ERRORDOCUMENT in an Apache Login environment where you do not allow guests the system goes into orbit. On my Motorola site I have had to use an ERRORDOCUMENT setting that directly to a static webpage because I have a DENYWEBVIEW = WikiGuest setting in all webs incl System web. People cannot register on my Moto site unless they can authenticate. The reason is that authentication and registration are not related at all.

So I would be happy with a different approach than the old. We just need to find a solution that works for both Apache and Template.

-- KennethLavrsen - 22 Jun 2010

The problem is in View.pm - it forces the browser status to 200. However when Apache asks the server to render the ErrorDocument, the view script should preserve the 401 status or the browser never will prompt for authentication.

Apache sets $ENV{REQUEST_STATUS} to 401 when requesting the ErrorDocument.

-- GeorgeClark - 22 Jun 2010

It is SVN distro:2c651ab54b6a that seems to cause the problem. And it is not too much 401 code. It is too little. George found this and will check in fix. But what about all the other scripts that distro:2c651ab54b6a altered? Will they also fail with Apache login in some cases?

-- KennethLavrsen - 22 Jun 2010

ok, I agree with Kenneth's point - my assumption that its better for us to set a status than to rely on the web server to figure one out is wrong. there are a number of other scenarios that make me think we should back these out, and only set a status when its actually necessary.

the reason for this is that we can't presume to predict users configurations - especially as apache / web server conf is a complex thing - and its not necessary for us to create artificial limitations.

-- SvenDowideit - 23 Jun 2010

Changing this to waiting for SvenDowideit

-- GeorgeClark - 02 Jul 2010

Here's another wrinkle: securing attachments using viewfile should be able to generate a 401 instead of delivering a foswiki error page with a 200 code.

As far as I can see, browsers will be happy to cache the 401 information but will most likely request a 200 frequently. So best would be to let viewfile - as well as rest - generate a 401.

-- MichaelDaum - 05 Jul 2010

your 'wrinkle' is how it works. There are other issues, but we really shouldn't load up this bug with other issues.

Kenneth - did my commit fix it?

-- SvenDowideit - 09 Jul 2010

Cannot see any issues with your fix

Closing as bug was not in 1.0.9

-- KennethLavrsen - 09 Jul 2010

Commenting is disabled while not logged in