Logout link redirects to non-Foswiki URL

I have HomePagePlugin installed, which correctly generates a Logout link, for example: http://my-company.com/wiki/System/PatternSkinCustomization?logout=1
This correctly respects the requirement to remain on a given page when logged out, though I expect a login form to be presented if UnknownUser is not authorized to view the page. This is the current behavior in a legacy Foswiki installation, version 1.1.3, from which I am upgrading.

The problem is that in the upgraded Foswiki installation (v.2.0.3), the logout URL above is apparently redirected to a URL that does not include the local "/wiki/" base URL for the Foswiki installation, to wit: http://my-company.com/System/PatternSkinCustomization This results in the user being presented with a site-wide ~~401~~ 404 error page, rather than a Foswiki page.

Is this an error in my Apache configuration (generated at Support/ApacheConfigGenerator), a problem in Foswiki's login manager, ... ?

Here is the Foswiki ApacheConfigGenerator comment string for my Apache configuration:

 
Generated at http://foswiki.org/Support/ApacheConfigGenerator?vhost=;port=;dir=/var/www/shared/wiki/foswiki/library2.0.3;symlink=;pathurl=/wiki;shorterurls=enabled;engine=CGI;fastcgimodule=fcgid;fcgidreqlen=;apver=2;confighost=;configip=;configuser=;loginmanager=Apache;htpath=/var/www/shared/wiki/foswiki/library2.0.3/data;errordocument=ResetPassword;errorcustom=;disablephp=on;blockpubhtml=on;blocktrashpub=on;controlattach=on;blockspiders=on;foswikiversion=2.0;apacheversion=2.4;timeout=8;ssl=;sslcert=/etc/ssl/apache2/yourservercert.pem;sslchain=/etc/ssl/apache2/sub.class1.server.ca.pem;sslkey=/etc/ssl/apache2/yourservercertkey.pem

-- StephenMossbarger - 18 Dec 2015

What are the following settings in your LocalSite.cfg?

$Foswiki::cfg{ScriptUrlPath} =
$Foswiki::cfg{ScriptUrlPaths}{view} =

Your apache configuration looks okay.

I'll have to set this up and test it. I've not tried HomePagePlugin with a ScriptUrlPath other than /bin. Actually in looking at the templates, the logout link is part of PatternSkin, and not generated by HomePagePlugin.

-- GeorgeClark - 18 Dec 2015

Hello George,

thanks for investigating.

$Foswiki::cfg{ScriptUrlPath} = '/wiki/bin';
$Foswiki::cfg{ScriptUrlPaths}{view} = '/wiki';

It does not appear that other Apache mod_rewrite configs in the vhost config are kicking in. Here are relevant consecutive lines in access log:

[visitor IP] my-company.com:80 - [18/Dec/2015:11:57:34 -0700] "GET /wiki/System/PatternSkinCustomization?logout=1 HTTP/1.1" 302 - "http://my-company.com/wiki/System/PatternSkinCustomization?validation_key=c179ec62d4bdc64f6dc5ff6327083891" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0"
[visitor IP] my-company.com:80 - [18/Dec/2015:11:57:34 -0700] "GET /System/PatternSkinCustomization HTTP/1.1" 404 2671 "http://my-company.com/wiki/System/PatternSkinCustomization?validation_key=c179ec62d4bdc64f6dc5ff6327083891" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0"

-- StephenMossbarger - 18 Dec 2015

I hate to say this but I'm unable to recreate your issue. I've configured Foswiki, and an apache web server for a similar URL:

$Foswiki::cfg{PubUrlPath} = '/wiki/pub';
$Foswiki::cfg{ScriptUrlPath} = '/wiki/bin';
$Foswiki::cfg{ScriptUrlPaths}{view} = '/wiki';

ScriptAlias /wiki/bin "/var/www/data/Foswiki-1.2.0/bin"
Alias /wiki/pub "/var/www/data/Foswiki-1.2.0/pub"
Alias /wiki "/var/www/data/Foswiki-1.2.0/bin/view/"
RewriteRule ^/+wiki/+bin/+view/+(.*) /wiki/$1 [L,NE,R]
RewriteRule ^/+wiki/+bin/+view$ /wiki [L,NE,R]

And the correct logout link is generated. Here is my access log:

f120.myco.com:80 127.0.0.1 - - [18/Dec/2015:14:43:33 -0500] "GET /wiki/System/PatternSkinCustomization?logout=1 HTTP/1.1" 302 355 "http://f120.myco.com/wiki/System/PatternSkinCustomization?validation_key=c3eb6bf7255327411a2649439f9853da" "Mozilla/5.
f120.myco.com:80 127.0.0.1 - - [18/Dec/2015:14:43:34 -0500] "GET /wiki/System/PatternSkinCustomization HTTP/1.1" 200 10481 "http://f120.myco.com/wiki/System/PatternSkinCustomization?validation_key=c3eb6bf7255327411a2649439f9853da" "Mozilla/5.0 (X11;

I'll dig a bit more, I'm not sure why you are having the issue. -- GeorgeClark - 18 Dec 2015

If you are up to do some debugging, I believe that the redirect is going wrong somewhere in lib/Foswiki/LoginManager.pm somewhere in the block starting around line 637. #TODO: consider if we should risk passing on the urlparams on logout. The path_info is recovered from the query and used in the redirect. For some reason the /wiki/ is being lost. Also it would be interesting to see the complete query string passed in from the browser when you click logout, from the firefox net debugging screen or a packet trace.

-- GeorgeClark - 18 Dec 2015

George, the correct logout link is sent according to Firefox Network debugger (see my initial report): http://my-company.com/wiki/System/PatternSkinCustomization?logout=1

According to the Firefox Network logger, the server's Location response to the request URI is: "http://my-company.com/System/PatternSkinCustomization" ("/wiki" is stripped out of or not added to the Location URL).

I believe you're right, that the problem is occurring somewhere in Foswiki's login manager, for whatever reason.

My LocalConfig and Apache foswiki config are set the same as yours.

Please note that I am using Foswiki version 2.0.3, not the 1.2.0 version you may be using judging from your LocalConfig filepath. Our current production wiki is Foswiki version 1.1.3, and it does not exhibit this server Location response behavior.

-- StephenMossbarger - 18 Dec 2015

I'm using 2.0.3 as well. The 1.2.0 path remains because I got tired of updating the path for each 2.0.x version I test. So I left it at 1.2.0 and symlink it to whatever I unzip.

-- GeorgeClark - 19 Dec 2015

This patch would give a bit of debug info. On my system it produced:

PATH_INFO recovered (/System/PatternSkinNavigation)
PATH_INFO sanitized: (/System/PatternSkinNavigation)
PATH_INFO encoded: (/System/PatternSkinNavigation)
redirectUrl: (http://f120.myco.com/wiki/System/PatternSkinNavigation)   (Yes really 2.0.3)

and the patch... To apply it, save this to a file patch.txt in your foswiki root (directory above lib), and patch it with

patch -p1 < patch.txt

diff --git a/lib/Foswiki/LoginManager.pm b/lib/Foswiki/LoginManager.pm
index 5b5ccd2..445b9be 100644
--- a/lib/Foswiki/LoginManager.pm
+++ b/lib/Foswiki/LoginManager.pm
@@ -636,19 +636,24 @@ sub redirectToLoggedOutUrl {
 
     #TODO: consider if we should risk passing on the urlparams on logout
     my $path_info = Foswiki::urlDecode( $session->{request}->path_info() );
+    print STDERR "PATH_INFO recovered ($path_info)\n";
+
     if ( my $topic = $session->{request}->param('topic') )
     {    #we should at least respect the ?topic= request
         my $topicRequest = Foswiki::Sandbox::untaintUnchecked($topic);
         ( my $web, $topic ) =
           $this->{session}->normalizeWebTopicName( undef, $topicRequest );
         $path_info = '/' . $web . '/' . $topic;
+        print STDERR "PATH_INFO param(topic) included: ($path_info)\n";
     }
 
     if ( $path_info =~ m/['"]/ ) {
         $path_info = substr( $path_info, 0, ( ( pos $path_info ) - 1 ) );
     }
+    print STDERR "PATH_INFO sanitized: ($path_info)\n";
 
     $path_info = Foswiki::urlEncode($path_info);
+    print STDERR "PATH_INFO encoded: ($path_info)\n";
 
     my $redirectUrl;
     if ( $Foswiki::cfg{ForceDefaultUrlHost} ) {
@@ -663,6 +668,7 @@ sub redirectToLoggedOutUrl {
     else {
         $redirectUrl = $session->{request}->referer();
     }
+    print STDERR "redirectUrl: ($redirectUrl)\n";
 
     #lets avoid infinite loops
     $session->{request}->delete('logout');

-- GeorgeClark - 19 Dec 2015

And reading that also says that if the "referrer" is wrong, that will break the logout. in which case enabling ForceDefaultUrlHost would fix it.

-- GeorgeClark - 19 Dec 2015

ForceDefaultUrlHost has been set to "1" in my config.

Changing this value to "0" has apparently solved the problem.

Again, many thanks!

-- StephenMossbarger - 21 Dec 2015

Okay. ForceDefaultUrlHost is the key. Do you use a "Reverse Proxy" or some other unusual configuration that requires the referrer: string to be ignored? If not, disabling ForceDefaultUrlHost should resolve the issue. The referrer is correct above, but it's not used in the redirect.

This is a bug with the ForceDefaultUrlHost option. It fails to insert the path. Setting this to Needs Task.

-- GeorgeClark - 21 Dec 2015

Tasks.Item13900 Filed. Note also, the issue has nothing to do with HomePagePlugin - It's a core issue.

-- GeorgeClark - 21 Dec 2015

Here is a patch you can try. I've tested it locally, recreated your issue, and this appears to fix it.

diff --git a/lib/Foswiki/LoginManager.pm b/lib/Foswiki/LoginManager.pm
index 5b5ccd2..0723145 100644
--- a/lib/Foswiki/LoginManager.pm
+++ b/lib/Foswiki/LoginManager.pm
@@ -655,7 +655,8 @@ sub redirectToLoggedOutUrl {
 
         # ForceDefaultUrlHost enabled - probably a reverse proxy.
         $path_info ||= '';
-        $redirectUrl = $session->{urlHost} . $path_info;
+        my $action = $session->{request}->{action} || 'view';
+        $redirectUrl = $session->getScriptUrl( '1', $action ) . $path_info;
     }
     elsif ($path_info) {
         $redirectUrl = $session->{request}->url() . $path_info;

-- GeorgeClark - 21 Dec 2015

Our installation does not require ignoring the Referer header; we don't currently run a reverse proxy. Unless there are security advantages to keeping it on, I will leave ForceDefaultUrlHost switched off in our upgraded wiki, though it is on in the previous legacy-version wiki config. Glad we've found the bug for a fix.

-- StephenMossbarger - 21 Dec 2015

No reason to enable that if you don't need it. It's an "expert" setting, hidden because it's seldom required. Re-reading the notes in bin/configure, it could also be needed by some SSL accelerators and SSL VPN gateways that alter the URL that the end user sees, compared to the URL known to foswiki.

Anyway, I've pushed the patch to 2.0.4 and 2.1 streams, so this will be fixed in the next release. Thanks for working with us on this.

-- GeorgeClark - 22 Dec 2015