You are here: Foswiki>Tasks Web>Item2549 (06 Jul 2015, GeorgeClark)Edit Attach

Item2549: Strange interaction between Foswiki::Engine::Apache (mod_perl) and Foswiki::LoginManager::ApacheLogin

pencil
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: ModPerlEngineContrib
Branches: master
Reported By: MarcSCHAEFER
Waiting For:
Last Change By: GeorgeClark
Apparently, either "view" is in CGI mode (not mod_perl) or auth basic doesn't work.

Symptom
  • with the below configuration
    • view is executed through mod_perl (which is the goal)
    • Edit button redirects straight to UserRegistration (there is no 4xx in the HTTP Answer), same as for the Login link.
  • if I modify the configuration adding the following at end
       <FilesMatch "^view$">
           SetHandler cgi-script
       </FilesMatch>
         
    the expected browser login windows appears.

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

ItemTemplate edit

Summary Strange interaction between Foswiki::Engine::Apache (mod_perl) and Foswiki::LoginManager::ApacheLogin
ReportedBy MarcSCHAEFER
Codebase 1.0.7
SVN Range
AppliesTo Extension
Component ModPerlEngineContrib
Priority Normal
CurrentState Closed
WaitingFor
Checkins ModPerlEngineContrib:0da83b5ea095 ModPerlEngineContrib:a663d7c8c009 distro:f706065fadb8 distro:8ad3c2bd01c2
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches master
trunkCheckins
masterCheckins distro:f706065fadb8 distro:8ad3c2bd01c2
ItemBranchCheckins
Release01x01Checkins
I Attachment Action Size Date Who Comment
ModPerlEngineContrib.patchpatch ModPerlEngineContrib.patch manage 1 K 02 Jan 2010 - 22:58 GilmarSantosJr <nop>ModPerlEngineContrib patch
apache.conf-generatedconf-generated apache.conf-generated manage 8 K 02 Jan 2010 - 18:34 MarcSCHAEFER Generated config file.
Topic revision: r13 - 06 Jul 2015, GeorgeClark
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy