Item2549: Strange interaction between Foswiki::Engine::Apache (mod_perl) and Foswiki::LoginManager::ApacheLogin
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
Apparently, either "view" is in CGI mode (not mod_perl) or auth basic doesn't work.
Symptom
Version
- Debian stable (lenny); fosiki packages 1.0.7-3
Excerpt from configuration:
<Directory "/var/lib/foswiki/bin">
AllowOverride None
Order Allow,Deny
Allow from all
Deny from env=blockAccess
Options +ExecCGI -FollowSymLinks
<IfModule mod_perl.c>
SetHandler perl-script
PerlResponseHandler Foswiki::Engine::Apache
</IfModule>
# Password file for Foswiki users
AuthUserFile /var/lib/foswiki/data/.htpasswd
AuthName 'Entrez votre WikiName (p.ex. GuillaumeTELL, sans espace). Faites Cancel/Annuler pour vous enregistrer.'
AuthType Basic
# File to return on access control error (e.g. wrong password)
ErrorDocument 401 /foswiki/bin/view/System/UserRegistration
# Make sure configure is not open to the general public.
# It exposes system details that can help attackers.
<FilesMatch "^(configure)$">
SetHandler cgi-script
Require user admin
</FilesMatch>
# When using Apache type login the following defines the Foswiki scripts
# that makes Apache ask the browser to authenticate. It is correct that
# scripts such as view are not authenticated.
<FilesMatch "(attach|edit|manage|rename|save|upload|mail|logon|rest|.*auth).*">
Require valid-user
</FilesMatch>
</Directory>
--
MarcSCHAEFER - 01 Jan 2010
Are you using ShortUrls? If so, try to use
ErrorDocument 401 /foswiki/System/UserRegistration
.
--
GilmarSantosJr - 01 Jan 2010
Yes, I am using ShortUrls, however mine don't have the /foswiki prefix.
- If I change as you propose, it works, except that hitting cancel on the browser-generated login window gives and authentification error and "Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."
- If I change as follows:
ErrorDocument 401 /System/UserRegistration
, then no browser-generated login window appears, and user is directed to the UserRegistration document as described above.
Strange!
--
MarcSCHAEFER - 02 Jan 2010
Marc, please test a config file generated by
ApacheConfigGenerator and report if the error persists. I have seen this error before and it was related to misconfigured ShortUrls.
--
GilmarSantosJr - 02 Jan 2010
Created
Item2550 because the "Addtionally, a 404 Not Found error was encountered" reminded me that we still have a serious defect with the
ApacheConfigGenerator that I had forgotten about.
Please try the fix there (add a new Alias directive above your existing 'Alias / "...') and report back
--
PaulHarvey - 02 Jan 2010
In my case, I don't have a ^/$ Alias or rewriting. Everything is a /foswiki/; however this is behind a proxy which does remove the /foswiki.
All my tests here have been done direct on the backend host, not through the proxy. So I don't think I have THAT problem.
My rewriting rule is (see above):
RewriteRule ^([A-Z].*) /foswiki/bin/view/$1 [PT] [L]
thus this can't match /error unless something is very wrong in the locale.
I will however try the config generator from scratch without all my fancy add-on.
--
MarcSCHAEFER - 02 Jan 2010
Ok, I just generated the config (attached as
apache.conf-generated), and the problem is the same: there is no browser login window when mod_perl is active, you get transferred directly to
UserRegistration.
Maybe for some reason when using mod_perl the error code 4xx is changed into 200 ? The returned HTTP headers are:
Response Headers
Date Sat, 02 Jan 2010 18:39:52 GMT
Server Apache/2.2.9 (Debian) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0
WWW-Authenticate Basic realm="Enter your WikiName: (First name and last name, no space, no dots, capitalized, e.g. JohnSmith). Cancel to register if you do not have one."
Set-Cookie FOSWIKISTRIKEONE=7dff0b1e84c0021fc43343911202917c; path=/ FOSWIKISID=31efa3be00cb37c5f63fcc3b59778c9c; path=/; HttpOnly
X-Foswikiuri /foswiki/bin/view/System/UserRegistration
Content-Length 34367
X-Foswikiaction view
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type text/html; charset=iso-8859-15
This is funny, because it is almost correct: just the return code is wrong (200). The rest is right (WWW-Authenticate e.g.). You don't get those if you don't do an Edit.
--
MarcSCHAEFER - 02 Jan 2010
I can confirm this behavior. Reading documentation.
--
GilmarSantosJr - 02 Jan 2010
This is a bug in
ModPerlEngineContrib. When Apache
generates a custom error message, it sets
REDIRECT_STATUS
variable and pass to the client the status generated by the script, instead of the original one. Please apply
this patch and report if the error persists.
--
GilmarSantosJr - 02 Jan 2010
Thank you, this fixed the problem for me.
My Foswiki installation is now running under mod_perl. This has a good impact on the time required to render the various topics (we gained about 800ms). Timing is now 631 ms (complex page with many DBQUERY), 641 ms (page with three SEARCHes and one CALENDAR, not yet migrated to DBQUERY), 280ms (basic page), 160ms (print)
This however created a new problem: Webs or topics which require authentification to be viewed no longer redirect to auth-basic. I will be investigating this. You can see what it does on
http://wiki.alphanet.ch/Phoenix/DocumentsAG2009 (requires to be authenticated) and compare it to
http://wiki.alphanet.ch/Phoenix/WebHome (doesn't need to be authenticated). I will try to debug this and report back.
--
MarcSCHAEFER - 03 Jan 2010
I performed some tests locally with foswiki versions
1.0.7
and
1.0.8
and I could not reproduce this new problem. If you are not authenticated, foswiki issues a redirect to
viewauth
and then the server prompts for authentication. Your site is generating the
Location
header field correctly, but it returns http status 200. Please review your proxy settings and try to reproduce the error using plain CGI.
--
GilmarSantosJr - 03 Jan 2010
I have reverted the patch which fixes the "edit goes straight to
UserRegistration without auth-basic browser requestor", and the new problem
"guest unreadable topic returns empty document" disappears. I have observed that when this bugs happens, res->status=302, REDIRECT_STATUS=200
and STATUS=200. Basically your patch assumes that REDIRECT_STATUS is unset, which is not always the case. Thus the best is to ignore REDIRECT_STATUS when it is 200.
I have now patched your patch as follows:
virtual:~# diff -uP /var/lib/vz/private/1[02]3/var/lib/foswiki/lib/Foswiki/Engine/Apache.pm
--- /var/lib/vz/private/103/var/lib/foswiki/lib/Foswiki/Engine/Apache.pm 2010-01-03 11:08:49.000000000 +0100
+++ /var/lib/vz/private/123/var/lib/foswiki/lib/Foswiki/Engine/Apache.pm 2010-01-03 16:45:20.000000000 +0100
@@ -210,10 +210,10 @@
my ( $this, $res, $req ) = @_;
$this->SUPER::finalizeHeaders( $res, $req );
- # If REDIRECT_STATUS is present, preserve it. See Foswikitask:Item2549
+ # If REDIRECT_STATUS is useful, preserve it. See Foswikitask:Item2549
# and http://httpd.apache.org/docs/2.2/en/custom-error.html#custom
my $status;
- if (defined $ENV{REDIRECT_STATUS}) {
+ if (defined $ENV{REDIRECT_STATUS} && ($ENV{REDIRECT_STATUS} != 200)) {
$status = $ENV{REDIRECT_STATUS};
}
elsif (defined $res->status && $res->status =~ /^\s*(\d{3})/o) {
This seems to fix both problems at the same time.
--
MarcSCHAEFER - 03 Jan 2010
Committed to svn. Thanks, Marc!
--
GilmarSantosJr - 03 Jan 2010