Item9941: Cache feature uses a 401 redirect which is not compatible with the suggested redirect to UserRegistration

When I enable the page cache feature and edit any topic I end up not saving anything and land on UserRegistration.

The reason is that I use the ApacheConfigGenerator given way to forward people that fail authentication to lead them to the registration page.

We need to document both in the ApacheConfigGenerator and PageCaching that you cannot use this setting with cache enabled.

Michael can you confirm my observation.

It is easy to fix the documentation here on foswiki.org. And maybe also in the installation doc. I just need the confirmation and I can do the docu.

-- KennethLavrsen - 02 Nov 2010

Where does the PageCache use a 401 redirect?

Not sure what the error actually is, nor could I imagine how registration could have something to do with PageCaching. Could you please elaborate your first sentence a bit more, please, Kenneth?

-- MichaelDaum - 02 Nov 2010

I re-created the foswiki.conf file from a fresh ApacheConfigGenerator run.

And with this I do not see the problem.

So there is something in my old config that creates the additional 401.

Not an urgent thing to find out. If a fresh apache config works I do not want to worry more about it in a 1.1.2 context. Changing to low and waiting for myself to find the exact root cause.

-- KennethLavrsen - 03 Nov 2010

I enabled cache on my Motion site.

Then the complaints came in. Noone could login. The login link ended up right away on UserRegistration

I think the cache wrongly caches the redirect to UserRegistration and it probably requires a failed login and a forward and then the cache keeps on serving this.

That does not work well. I have turned the cache off now.

Back to urgent release blocker

-- KennethLavrsen - 05 Nov 2010

Ah! Foswiki serves the UserRegistration topic on a totally unrelated url, that is the restricted topic is not redirecting to http://.../System/UserRefrustration and instead is rendering this page on a different url? Is that the case?

That's bound to cause any sort of trouble anyway. We should make this a proper redirect. So the error is that the core does not issue a redirect where it should to map the right content to the right url.

In addition could you please detail which login and password manager you are using, as well as your specific apache cfg, just to get the full picture.

-- MichaelDaum - 05 Nov 2010

I will try and reproduce this more carefully.

Here is the some quick information. But I will be back with more Sunday.

• The site is my public http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome site
• Release 1.1.1 + more or less all patches on Release01x01 branch so use Release01x01 as it is now.
• ApacheLogin with normal HtPasswd manager.
• Apache config like ApacheConfigGenerator suggests
• No short URL.
• No persistant perl. Plain CGI
• Plugins can be seen here http://www.lavrsen.dk/foswiki/bin/view/System/InstalledPlugins
• Centos box pretty up to date with Centos and perl is the 5.8.8 that Centos ships with
• Cache used was the default for both topic and meta. Ie. just enabled the cache in configure and no changes.
• Cache had worked fine as I tested it.
• Cache is turned off now as I have quite a lot of traffic on the Motion site so I cannot allow it to not work

I am working on getting my public test site to do the same but since I am out Saturday it will have to wait till Sunday.

As far as I can tell - removing the ErrorDocument 401 /foswiki11/bin/view/System/UserRegistration from the apache config cures the problem so it is somehow related to redirects. You are supposed to be redirected to 401 when authentication fails.

On my Motorola site I do not have same problem because it is not accessible at all without authenticating first so redirecting to a Foswiki page just puts the whole thing into a loop from hell. So there I use the default 401 redirect.

When the site failed it was when you clicked the login link in the upper left bar of Patternskin and it took you straight to UserRegistration without the normal prompt for user name and password that should pop up in the browser with ApacheLogin.

Hope this gives some hint. Otherwise I will find the exact step by step to reproduce it on Sunday afternoon.

-- KennethLavrsen - 05 Nov 2010

I decided to give it 5 minutes here Saturday night

I can reproduce it easily on Release01x01 on http://merlin.lavrsen.dk

All I do is enable the cache. Try and login, make it fail once close the browser, open again and click login. And from then on I see the registration page.

Here is an important info though.

The URL in the browser is http://merlin.lavrsen.dk/foswiki11/bin/logon/Main/WebHome and not the URL for the UserRegistration page. So it seems the cache saves the UserRegistration page and show that and prevents the normal authentication. The browser does not even prompt you for username and password.

If I click Edit I should be prompted for user name and password. That also shows the UserRegistration page in the browser. But URL stays the same.

I can then navigate to another page. Viewing is fine. I go to another page. Click edit. And I see the UserRegistration page again. But still with another URL. In this case I see a URL like http://merlin.lavrsen.dk/foswiki11/bin/edit/Myweb/WebHome?t=1288988851;nowysiwyg=1 but the content in the browser is UserRegistration.

It is like the cache kicks in no matter what and shows this page.

I went back to just viewing a page.

And then I went "behind the webserver" and deleted the entire cache in working/tmp/cache.

And then I clicked edit again and I am now prompted for user name and password and I can edit pages like normal.

Then I close the browser. Open a new browser. Click on the login link and I am immediately in UserRegistration hell again.

The last observation is that I believe the trigger of the problem is easier when the browser is Internet Explorer. I run IE8.

You should have enough to reproduce it now.

-- KennethLavrsen - 05 Nov 2010

One more observation. Once the UserRegistration hell has started I cannot even get into configure. I cannot turn off the cache from the browser. I have to hack the config or delete the cache to get to configure.

It seems the cache should only work with view and not with logon or configure etc etc.

When you authenticate with ApacheLogin I actually think a 401 is done with the UserRegistration URL and the browser continues to this URL only if the authentication fails, otherwise it go to the original URL.

We need the cache to never cache unless we are under a normal 200 return code.

-- KennethLavrsen - 05 Nov 2010

I have seen this behaviour too. Except I am still able to get to configure (this is on trunk).

-- PaulHarvey - 06 Nov 2010

Okay can't say what this is without reproducing it myself.

-- MichaelDaum - 07 Nov 2010

If we do not have a safe easy fix for 1.1.2 then it is not serious. We just need to document that ErrorDocument 401 must be default and not defined when using cache. Then it works fine. That is not a show stopper.

Docu goes in PageCaching and the apache config generator

-- KennethLavrsen - 07 Nov 2010

In any case it needs a proper analysis. From that point on I can't see why we should not fix this.

-- MichaelDaum - 08 Nov 2010

Never suggested not to fix. I was only referring to 1.1.2

-- KennethLavrsen - 08 Nov 2010

Here is what happens:

First time the page is requested, foswiki redirects to logon or viewauth. Apache answers with a 401 and the browser pops up the auth window. When you click on cancel now, apache will redirect the 401 page to /view/System/UserRegistration. This is a normal view for foswiki even though the url in the address bar is .../bin/login (or viewauth). That's why it happy computes the page and stores it into the cache. Now, the second time this happens, it finds the very same UserRegistration page in the cache and returns a 304 Not modified. Similarly, when foswiki returns a 200.

Now the error manifests: instead of apache answering with another 401, it reroutes the 304 or 200 response from the PageCache to the browser ... which then rejects to pop up yet another auth dialog...

Here's a quick fix which works around this:

--- lib/Foswiki/UI/View.pm      (revision 9900)
+++ lib/Foswiki/UI/View.pm      (working copy)
@@ -66,7 +66,7 @@
             $session->{response}->redirect( $cachedPage->{location} );
         }
         else {
-            $session->{response}->status($status);
+            $session->{response}->status($status) unless $status eq 200;
         }

It prevents a 200 from being set from within the page cache. That way it won't override a 401 that apache must generate.

-- MichaelDaum - 08 Nov 2010

Thanks for the fix.

I have tested it and I can confirm that with this I cannot provoke the error.

I check in the fix and set the bug Waiting For Release.

Thanks again Michael for spending the time analysing this. It was much better to get a real fix into 1.1.2 then my suggested docu work around.

-- KennethLavrsen - 08 Nov 2010

Commenting is disabled while not logged in