This question about Installation of Foswiki, Authentication or Authorisation: Task filed

Cannot Login after upgrade from 1.1.9 to 2.1.3

Hello!

I have problems logging in to my new Foswiki installation after upgrade from version 1.1.9 to 2.1.3.

As it is said in the UpgradeGuide, I have set up a new directory for the new version, extracted the distribution package, went through initial configure steps via web interface, and then copied over user and group pages and the .htpasswd file from old data. I have also set the internal admin password in the configure interface.

After that, I cannot login to my new site. There are no errors, but either the TemplateLogin form comes back, or a wiki page is rendered for guest user.

This is how it looks like in the events log:

| 2017-05-05T13:57:54+03:00 info | admin | login | Main.WebHome | AUTHENTICATION SUCCESS - admin - Chrome | x.x.192.193 |
| 2017-05-05T13:58:12+03:00 info | guest | view | Main.WebHome | (GET) Chrome | x.x.192.193 |
| 2017-05-05T13:59:02+03:00 info | alex | login | Main.WebHome | AUTHENTICATION SUCCESS - alex - Firefox | x.x.192.193 |
| 2017-05-05T13:59:03+03:00 info | guest | view | Main.WebHome | (GET) Firefox | x.x.192.193 |

The LoginManager is TemplateLogin, and {Register}{AllowLoginName} option is enabled.

This is one login attempt in my webserver CGI log:

SESSION ?: loadSession
SESSION ?(c): Cookie FOSWIKIPREF=%7CTwistyPlugin_topicattachmentslist1%3D1%7CTwistyPlugin_edithelp%3D0%7CEditTextareaFontStyle%3Dproportional; _redmine_session=BAh7CzoKYXRpbWVsKwe
18gtZOgpjdGltZWwrB53yC1k6EF9jc3JmX3Rva2VuIjEweVRybk04RURHNVo4M2IxakpsbjlTSkJQK3BvSW9HZ2FkZW9TT2l6WmdzPToPc2Vzc2lvbl9pZCIlNDcyMWFhN2VhMDIwZWRhN2UxNzA4OGQ2NjBlMTg4M2YiFXVzZXJzX2luZG
V4X3NvcnQiCmxvZ2luOgx1c2VyX2lkaQg%3D--bd77112c4b879b038728c4a2265853c48fab9f2a; SFOSWIKISID=64a0cdd26ac8129131e1faff5c4e3e7f; FOSWIKISTRIKEONE=21f5353d970b4cdf34ffa65b5b1e44d2
SESSION ?(c):  ... Found session id 64a0cdd26ac8129131e1faff5c4e3e7f;
SESSION ?(c): _loadCreateCGISession called ...
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): No session, checking URI Params for a user
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Falling back to DEFAULT USER: guest
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): userLoggedIn called with guest - undef
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): ====   Initial user is guest
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Session is NOT authenticated
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Setting internal preference VALID_ACTIONS to HASH(0x1683380)
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Setting internal preference REMEMBER to null
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Setting internal preference FOSWIKISTRIKEONE to 21f5353d970b4cdf34ffa65b5b1e44d2
SSESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): userLoggedIn called with alex - undef
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): ====   Initial user is guest
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Authenticated; converting from guest to alex - default guest
SESSION 64a0cdd26ac8129131e1faff5c4e3e7f(c): Replace the session guest -> alex
SESSION ?(c): _loadCreateCGISession called ...
SESSION 60d29c2bc719bb10790b054780db8228(c): Changed SID from 64a0cdd26ac8129131e1faff5c4e3e7f to 60d29c2bc719bb10790b054780db8228
SESSION 60d29c2bc719bb10790b054780db8228(c):  - VALID_ACTIONS = HASH(0x1683380)
SESSION 60d29c2bc719bb10790b054780db8228(c):  - REMEMBER = undef
SESSION 60d29c2bc719bb10790b054780db8228(c):  - AUTHUSER = alex
SESSION 60d29c2bc719bb10790b054780db8228(c):  - FOSWIKISTRIKEONE = 21f5353d970b4cdf34ffa65b5b1e44d2

=== Login appears to work - SID changed from 64a... to 60d... ===

SESSION ?: loadSession
SESSION ?(c): Cookie FOSWIKIPREF=%7CTwistyPlugin_topicattachmentslist1%3D1%7CTwistyPlugin_edithelp%3D0%7CEditTextareaFontStyle%3Dproportional; _redmine_session=BAh7CzoKYXRpbWVsKwe18gtZOgpjdGltZWwrB53yC1k6EF9jc3JmX3Rva2VuIjEweVRybk04RURHNVo4M2IxakpsbjlTSkJQK3BvSW9HZ2FkZW9TT2l6WmdzPToPc2Vzc2lvbl9pZCIlNDcyMWFhN2VhMDIwZWRhN2UxNzA4OGQ2NjBlMTg4M2YiFXVzZXJzX2luZGV4X3NvcnQiCmxvZ2luOgx1c2VyX2lkaQg%3D--bd77112c4b879b038728c4a2265853c48fab9f2a; SFOSWIKISID=64a0cdd26ac8129131e1faff5c4e3e7f; FOSWIKISTRIKEONE=21f5353d970b4cdf34ffa65b5b1e44d2

====  FAILURE Here.   Note that the SFOSWIKISID cookie is still 64a...   which is the old guest session ===

SESSION ?(c):  ... Found session id 64a0cdd26ac8129131e1faff5c4e3e7f;
SESSION ?(c): _loadCreateCGISession called ...
SESSION 145e1240c525609c29067af7e6a53877(c): No session, checking URI Params for a user

=== And the original 64a... cookie has been removed from disk,  so yet another session is created 145e...  ===

SESSION 145e1240c525609c29067af7e6a53877(c): Falling back to DEFAULT USER: guest
SESSION 145e1240c525609c29067af7e6a53877(c): userLoggedIn called with guest - undef
SESSION 145e1240c525609c29067af7e6a53877(c): ====   Initial user is guest
SESSION 145e1240c525609c29067af7e6a53877(c): Session is NOT authenticated

What is wrong with my CGI sessions setup?

-- AlexanderSmishlajev - 05 May 2017

Are you using a mix of http and https? it looks like the cookie (SFOSWIKISID) is the one generated for https sites. Make sure you are not redirecting between http and https, and try clearing all the browser cookies.

-- GeorgeClark - 05 May 2017

I have tried it from private browser window with the same effect.

As far as I see, I use https only. DefaultUrlHost in LocalSite.cfg is https, and I have double-checked that my web server returns 404 for http requests to wiki paths.

Foswiki 1.1.9 works Ok on the same server with the same setup (only the path is different).

-- AlexanderSmishlajev - 06 May 2017

Currently the cookie path cannot be used to separate two foswiki sites. If the only difference between the two sites is the path: ie: https:yoursite.com/foswiki1/... vs. https://yoursite.com/foswiki2/..., you've encountered a limitation in Foswiki 2.1. The complete fix is not yet released. It will be included in the upcoming Foswiki 2.2. The issue is that not all of the cookies generated by Foswiki incorporate the path, or they use a hardcoded path, and you get collisions.

Unfortunately even with the changes for Tasks.Item14281, some of the cookies still use a hardcoded path and name. We don't have a good solution currently other than to use a different virtualhost name. Foswiki 2.2 will allow the cookie name to be altered using a new configuration parameter: {Sessions}{CookieNamePrefix}, but we are not yet ready to release Foswiki 2.2. The planned changes in Foswiki 2.2 are described in ConfigurableCookieNamesAndPaths. The work remaining is to convert to a different javascript library for interacting with the cookies, so that more flexibility is possible.

-- GeorgeClark - 06 May 2017

Uh. Sorry, I do not see how that might affect logging in from a private browser window - i.e. initially without any cookies.

Of course, I get logged out from one wiki when I log in to another one - that is expected and totally fine by me because the two wikis co-exist only until the upgrade is done, according to the official Foswiki docs.

The problem is that after successful authentication with Foswiki 2.1.3 - which I see in the logs only - immediately current page is rendered for guest user.

-- AlexanderSmishlajev - 06 May 2017

The session is composed of two parts:
  • The SFOSWIKISID cookie - which has a [sha1-hash-identifier]
  • The CGI Session file, saved in the working/tmp/cgisess_[sha1-hash-identifier]

With both Foswiki's using the hardcoded path of "/", the browser has a common cookie for both sites. But the two sites each have unique working/tmp directories.

I don't believe that Private Window is doing what you expect with regard to cookies, at least in Firefox. I just tried logging into foswiki.org using a private window. and then displayed the cookie information. The same cookies and session-id were displayed in both the private window, and in the regular session.

Try clearing the all the domain cookies for your site. Then access your 2.1.3 system, without accessing the 1.1.9 system at all. See if that helps.

-- GeorgeClark - 06 May 2017

Thank you very much for your help, George!

I am sorry, but clearing out all cookie data didn't work. I have tried that with Google Chrome and Microsoft Edge. Same result.

-- AlexanderSmishlajev - 06 May 2017

I have symlinked working/tmp from v1.1.9 to new installation and then tried to login with Google Chrome incognito window. Same result.

-- AlexanderSmishlajev - 06 May 2017

I'm really at a loss. Here is a similar login on my local test system, with some annotation: I'll also edit and comment on your trace above.

SESSION ?: loadSession
SESSION ?(c): Cookie FOSWIKI_UPDATESPLUGIN=0; FOSWIKISID=dbaac9e24c6e80bfcae429969a62383d; FOSWIKISTRIKEONE=da2e9241d90de64d7bc8adb71c3d6552
SESSION ?(c):  ... Found session id dbaac9e24c6e80bfcae429969a62383d;
SESSION ?(c): _loadCreateCGISession called ...
SESSION dbaac9e24c6e80bfcae429969a62383d(c): No session, checking URI Params for a user
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Falling back to DEFAULT USER: guest
SESSION dbaac9e24c6e80bfcae429969a62383d(c): userLoggedIn called with guest - undef
SESSION dbaac9e24c6e80bfcae429969a62383d(c): ====   Initial user is guest
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Session is NOT authenticated
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Setting internal preference VALID_ACTIONS to HASH(0x2a576c0)
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Setting internal preference REMEMBER to null
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Setting internal preference FOSWIKISTRIKEONE to da2e9241d90de64d7bc8adb71c3d6552
SESSION dbaac9e24c6e80bfcae429969a62383d(c): userLoggedIn called with JoeUser - undef
SESSION dbaac9e24c6e80bfcae429969a62383d(c): ====   Initial user is guest
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Authenticated; converting from guest to JoeUser - default guest
SESSION dbaac9e24c6e80bfcae429969a62383d(c): Replace the session guest -> JoeUser 
SESSION ?(c): _loadCreateCGISession called ...
SESSION e105c27f9c787af58b671d1bae521a2e(c): Changed SID from dbaac9e24c6e80bfcae429969a62383d to e105c27f9c787af58b671d1bae521a2e
SESSION e105c27f9c787af58b671d1bae521a2e(c):  - VALID_ACTIONS = HASH(0x2a576c0)
SESSION e105c27f9c787af58b671d1bae521a2e(c):  - FOSWIKISTRIKEONE = da2e9241d90de64d7bc8adb71c3d6552
SESSION e105c27f9c787af58b671d1bae521a2e(c):  - AUTHUSER = JoeUser
SESSION e105c27f9c787af58b671d1bae521a2e(c):  - REMEMBER = undef

=== The above login has changed the session ID from dbaa... to e105...    This should be seen in the cookie on the next transaction: ===

DEVELOPER WARNING: taint mode could not be enabled. Is Taint::Runtime installed?
SESSION ?: loadSession
SESSION ?(c): Cookie FOSWIKI_UPDATESPLUGIN=0; FOSWIKISID=e105c27f9c787af58b671d1bae521a2e; 

== The FOSWIKISID cookie ... e105...   is the new session ID created by the login.   This information comes from the browser. ==

FOSWIKISTRIKEONE=da2e9241d90de64d7bc8adb71c3d6552
SESSION ?(c):  ... Found session id e105c27f9c787af58b671d1bae521a2e;
SESSION ?(c): _loadCreateCGISession called ...
SESSION e105c27f9c787af58b671d1bae521a2e(c): AUTHUSER from session is JoeUser
SESSION e105c27f9c787af58b671d1bae521a2e(c): userLoggedIn called with JoeUser - undef
SESSION e105c27f9c787af58b671d1bae521a2e(c): ====   Initial user is JoeUser
SESSION e105c27f9c787af58b671d1bae521a2e(c): Authenticated; converting from JoeUser to JoeUser - default guest
SESSION e105c27f9c787af58b671d1bae521a2e(c): Setting internal preference VALIDATION to 1
SESSION e105c27f9c787af58b671d1bae521a2e(c): Setting internal preference FOSWIKISTRIKEONE to da2e9241d90de64d7bc8adb71c3d6552
SESSION e105c27f9c787af58b671d1bae521a2e(c): Setting internal preference REMEMBER to null
SESSION e105c27f9c787af58b671d1bae521a2e(c): Setting internal preference AUTHUSER to JoeUser
SESSION e105c27f9c787af58b671d1bae521a2e(c): Setting internal preference VALID_ACTIONS to HASH(0x45b4c60)

===- And the session "sticks" as the next transaction also has the same ID.===

DEVELOPER WARNING: taint mode could not be enabled. Is Taint::Runtime installed?
SESSION ?: loadSession
SESSION ?(c): Cookie FOSWIKI_UPDATESPLUGIN=0; FOSWIKISID=e105c27f9c787af58b671d1bae521a2e; 

I suspect the issue is the browser is for some reason sending back the wrong cookie, and I'm not sure why.

-- GeorgeClark - 06 May 2017

Since you are running in "private mode" one of the things is that "cookies are not saved". Is that what could be causing your original session cookie to remain, rather than allowing it to be replaced by the new SID cookie?

-- GeorgeClark - 06 May 2017

Would you suggest any debug prints I could insert into Foswiki library to understand what's going on?

-- AlexanderSmishlajev - 06 May 2017

I have just tried that with Google Chrome without "incognito". Same result.

-- AlexanderSmishlajev - 06 May 2017

I'm pretty sure that the issue is on the browser side and it is not remembering the new cookie ID. You won't be able to use Foswiki with private browser windows.

One major change in Foswiki 2.x is that we now "rotate" Session ID's on every change in identity. Foswiki 1.1 would never change a Session ID. Use of a private browser window would work fine because the cookies never change. This however introduced a security exposure, in that if someone "guessed" the SID, or somehow injected a different SID into an existing session, it was possible to hijack the session. This type of attack is called a "session fixation attack". Generating a new unique session ID on login is a way to mitigate the exposure.

Following recommended best practices, Foswiki 2.1 creates a new unique Session ID (SFOSWIKISID cookie) for every change in identity. This blocks certain session hijack attacks. But the browser must be able to accept a changed cookie for every identity change.

-- GeorgeClark - 06 May 2017

I'm not sure what else to suggest. In your trace, there is a Changed SID message. That shows the new Session ID. If you inspect the browser's cookies, you should see a SFOSWIKISID cookie with that value. If they don't match, the login won't work.

Only other 1.x to 2.x difference I can think of. In Foswiki 2.x, we us IP Matching as well in the CGI Session. This is also to prevent certain attacks, but will break things when using proxies or anything that "roams" the client across IP addresses. That may need to be disabled. But I don't think that's involved in this situation as the cookie sent by the browser didn't change on login.

-- GeorgeClark - 06 May 2017

Ok, I understand that I shouldn't use private windows for testing.

I have tried to log in with normal Google Chome window. After that, I examined all cookies set in Chrome. There is no cookie set for my domain.

For me, it seems that the whole thing occurs within one CGI run - that is, authentication code runs Ok, and then it returns program control to rendering, and somehow in that pass of control we lose the authenticated user data. Is there any way to debug that?

-- AlexanderSmishlajev - 06 May 2017

Maybe a network trace? Firefox has and hopefully chrome has a panel that shows all the network traffic including the headers for the request. Do you have an extension enabled in the browser that might be blocking cookies? I know of nothing in Foswiki that would be removing cookies. We run our live production code on https://foswiki.org, https://blog.foswiki.org. Those two domains are configured to share cookies. In addition the foswiki.org site supports http: protocol, and is configured to redirect to https on login, or with any action that requires validation. These are all working fine. We also run https://trunk.foswiki.org which shares the .htpasswd file and some webs with the other sites. That is running our 2.2 alpha code.

In addition I quickly configured my local server to use a path ... local.org/wiki/... and the cookies seem to be behaving correctly.

Do you have any sort of a proxy or gateway between your client and host that might be stripping cookies or otherwise altering things?

-- GeorgeClark - 06 May 2017

Just a bit more information. After a normal foswiki Login you should see 2-5 cookies.
  • FOSWIKISID - Set if the session was created over http.
  • FOSWIKISID - Set if the session was created over http.
  • SFOSWIKISID - Set if the session created over https.
  • SFOSWIKISID - Set if the session created over https.
Note that there is an expert setting to disable Sessions for guests. If enabled, then the *SID cookies will only exist after a user logs in. But default is always to create a session.
  • FOSWIKISTRIKEONE - Created for "Validation" to prevent certain xss / replay attacks.
  • FOSWIKISTRIKEONE - Created for "Validation" to prevent certain xss / replay attacks.
  • FOSWIKI_UPDATESPLUGIN - Created only for admin users to track extension update information
  • FOSWIKIPREF - Used by TwistyPlugin to remember preferences - if you've visited a page with Twisties.

-- GeorgeClark - 06 May 2017

The only time I've seen "0 cookies" created is when viewing foswiki as a guest, and $Foswiki::cfg{Sessions}{EnableGuestSessions} = 0;. But as soon as I log in, I get 2 cookies - FOSWIKISID and FOSWIKISTRIKEONE.

-- GeorgeClark - 06 May 2017

Yes, I am on a cellular connection, and perhaps my provider has a transparent proxy. Following is a Google Chrome output from chrome://net-internals/#events for one login attempt:

1925 URL_REQUEST https://www.mydomain.com/wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view/Main/WebHome

1927 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view/Main/WebHome
1928 HTTP_STREAM_JOB_CONTROLLER https://www.mydomain.com/wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view/Main/WebHome
1929 HTTP_STREAM_JOB https://www.mydomain.com/
1930 UDP_SOCKET [2001:4860:4860::8888]:53
1931 SSL_CONNECT_JOB ssl/www.mydomain.com:443
1932 TRANSPORT_CONNECT_JOB ssl/www.mydomain.com:443
1933 HOST_RESOLVER_IMPL_JOB www.mydomain.com
1934 SOCKET ssl/www.mydomain.com:443
1935 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.css?version=3.0
1937 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.css?version=3.0
1938 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/SmiliesPlugin/smilies.css
1940 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/SmiliesPlugin/smilies.css
1941 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/SkinTemplates/base.css
1943 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/SkinTemplates/base.css
1944 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/layout.css
1946 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/layout.css
1947 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/style.css
1949 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/style.css
1950 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/colors.css
1952 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/column_left.css
1953 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/colors.css
1955 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/variant_foswiki_noframe.css
1956 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/column_left.css
1958 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/variant_foswiki_noframe.css
1959 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkin/print.css
1961 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/jquery-2.2.4.js
1962 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/livequery/jquery.livequery.js?version=1.3.1
1963 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/migrate/jquery.migrate.js?version=1.4.1
1964 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js?version=2.11
1965 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.js?version=3.0
1966 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiString.js
1967 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiForm.js
1968 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiPref.js
1969 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/strikeone.js
1970 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkin/pattern.js
1971 DISK_CACHE_ENTRY foswiki-logo.png
1972 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkin/print.css
1973 UDP_SOCKET
1974 UDP_SOCKET
1975 URL_REQUEST https://clients2.google.com/service/update2?cup2key=6:3018057659&cup2hreq=5517f538054234d1c9598171ac60762853fc513b87478df79e03f936a5752ba3
1976 HTTP_STREAM_JOB_CONTROLLER https://clients2.google.com/service/update2?cup2key=6:3018057659&cup2hreq=5517f538054234d1c9598171ac60762853fc513b87478df79e03f936a5752ba3
1977 HTTP_STREAM_JOB https://clients2.google.com/
1978 UDP_SOCKET [2001:4860:4860::8888]:53
1979 SSL_CONNECT_JOB pm/ssl/clients2.google.com:443
1980 TRANSPORT_CONNECT_JOB pm/ssl/clients2.google.com:443
1981 HOST_RESOLVER_IMPL_JOB clients2.google.com
1982 SOCKET pm/ssl/clients2.google.com:443
1983 HTTP2_SESSION clients2.google.com:443 (DIRECT)
1984 URL_REQUEST https://www.mydomain.com/wiki2/bin/login/Main/WebHome
1986 DISK_CACHE_ENTRY 1494089722851813/https://www.mydomain.com/wiki2/bin/login/Main/WebHome
1987 HTTP_STREAM_JOB_CONTROLLER https://www.mydomain.com/wiki2/bin/login/Main/WebHome
1988 HTTP_STREAM_JOB https://www.mydomain.com/
1989 UDP_SOCKET [2001:4860:4860::8888]:53
1990 SSL_CONNECT_JOB ssl/www.mydomain.com:443
1991 TRANSPORT_CONNECT_JOB ssl/www.mydomain.com:443
1992 HOST_RESOLVER_IMPL_JOB www.mydomain.com
1993 SOCKET ssl/www.mydomain.com:443
1994 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.css?version=3.0
1996 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.css?version=3.0
1997 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/SmiliesPlugin/smilies.css
1999 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/SmiliesPlugin/smilies.css
2000 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/SkinTemplates/base.css
2002 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/layout.css
2004 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/SkinTemplates/base.css
2005 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/style.css
2007 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/layout.css
2008 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/style.css
2009 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/colors.css
2011 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/colors.css
2012 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/column_left.css
2014 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/column_left.css
2015 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/variant_foswiki_noframe.css
2017 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkinTheme/variant_foswiki_noframe.css
2018 URL_REQUEST https://www.mydomain.com/wiki2/pub/System/PatternSkin/print.css
2020 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/jquery-2.2.4.js
2021 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/livequery/jquery.livequery.js?version=1.3.1
2022 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/migrate/jquery.migrate.js?version=1.4.1
2023 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js?version=2.11
2024 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/CommentPlugin/comment.js?version=3.0
2025 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiString.js
2026 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiForm.js
2027 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/foswikiPref.js
2028 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/JavascriptFiles/strikeone.js
2029 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkin/pattern.js
2030 DISK_CACHE_ENTRY foswiki-logo.png
2031 DISK_CACHE_ENTRY key.png
2032 DISK_CACHE_ENTRY add.png
2033 DISK_CACHE_ENTRY newtopic.png
2034 DISK_CACHE_ENTRY index.png
2035 DISK_CACHE_ENTRY searchtopic.png
2036 DISK_CACHE_ENTRY changes.png
2037 DISK_CACHE_ENTRY notify.png
2038 DISK_CACHE_ENTRY feed.png
2039 DISK_CACHE_ENTRY statistics.png
2040 DISK_CACHE_ENTRY wrench.png
2041 DISK_CACHE_ENTRY person.png
2042 DISK_CACHE_ENTRY group.png
2043 DISK_CACHE_ENTRY web-bg.png
2044 DISK_CACHE_ENTRY foswiki-badge.png
2045 DISK_CACHE_ENTRY https://www.mydomain.com/wiki2/pub/System/PatternSkin/print.css
2046 DISK_CACHE_ENTRY header5.gif
-- AlexanderSmishlajev - 06 May 2017

Try disabling $Foswiki::cfg{Sessions}{UseIPMatching}. Unfortunately that trace doesn't help much as it is not showing the request/response headers.

-- GeorgeClark - 06 May 2017

Uh, sorry, seeems that we both have written at the same time. I have looked up the EnableGuestSessions ssetting, and it was on, and I have turned it off, and that didn't change anything.

-- AlexanderSmishlajev - 06 May 2017

I have turned UseIPMatching off, same result.

-- AlexanderSmishlajev - 06 May 2017

No the EnableGuestSessions doesn't apply in your case. It's mostly helpful for public sites were "bots" hit 1000's of page and flood the site with sessions.

But the UseIPMatching indeed might be related, although it does not explain seeing 0 cookies. All that would do is cause a new session to be created on IP address change.

-- GeorgeClark - 06 May 2017

I'm at a complete loss. Is there another client you could try.

On "Chrome" to see the headers.
  • go to the tools -> developer tools menu.
  • Load the page - yoursite.com/wiki1/Main/WebHome.
  • In the developer tools, scroll to the top and click the first entry, which should be the WebHome page
  • Under the "Response Headers" section you should see something like:
Connection:Keep-Alive
Content-Length:0
Content-Type:text/html; charset=utf-8
Date:Sat, 06 May 2017 17:22:24 GMT
Keep-Alive:timeout=5, max=80
Location:/wiki/
Set-Cookie:FOSWIKISID=b69f2fd75aa81a1603a0538bccae2450; path=/; HttpOnly
Set-Cookie:FOSWIKISTRIKEONE=ab7f2808d00d5337cebcafb0c8e1f0a9; path=/

-- GeorgeClark - 06 May 2017

These are the headers of my WebHome page:

HTTP/1.1 200 OK
X-Foswiki-Monitor-Rendertime: 0.574254
X-Foswikiuri: /wiki2/bin/view/Main/WebHome
Content-Length: 17891
X-Foswikiaction: view
X-Foswiki-Validation: ba549019e5dff93ae41c78f1be3b1ff4
Cache-Control: max-age=0
Content-Type: text/html; charset=utf-8
Set-Cookie: SFOSWIKISID=47cd50cd0cbfe045bdefb0881c079f6f; path=/; secure; HttpOnly
Set-Cookie: FOSWIKISTRIKEONE=cb525133f35fb380a6d8578ab417c8cf; path=/; secure
Date: Sun, 07 May 2017 05:22:00 GMT
Server: lighttpd/1.4.41

-- AlexanderSmishlajev - 07 May 2017

So based on this, the server is returning the cookie headers. If they are not being saved and returned by the browser then something is blocking it on the client side. I really don't have any other ideas.

-- GeorgeClark - 07 May 2017

No, sorry, the whole thing occurs within one HTTP request.

Normally, when I submit the login form, I get back a wiki page rendered for authenticated user whose credentials were submitted. With this installation, I get back a page rendered for guest user. There are no more requests from the browser, just submit of the login form.

These lines appear in the Chrome console:

Navigated to https://www.medaplis.lv/wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view
Navigated to https://www.medaplis.lv/wiki2/bin/login/Main/WebHome

The first line - with foswiki_origin parameter - is request for the login form, and the second request is submit. No more HTTP requests, I already get WebHome page with "Log In" link instead of user name.

These are the last two lines in HTTP server access log:
x.x.192.55 www.mydomain.com - [07/May/2017:16:45:40 +0300] "GET /wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view HTTP/1.1" 200 8332 "https://www.mydomain.com/wiki2/bin/view" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36"
x.x.192.55 www.mydomain.com - [07/May/2017:16:46:06 +0300] "POST /wiki2/bin/login/Main/WebHome HTTP/1.1" 200 17979 "https://www.mydomain.com/wiki2/bin/login/Main/WebHome?foswiki_origin=GET%2cview%2c/wiki2/bin/view" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36"

-- AlexanderSmishlajev - 07 May 2017

All I can think of now is that it's something specific to Lighttpd or the host server. Any chance you could attach your lighttpd configuration files for the two wiki installations to this topic. Sanitize out any sensitive information. I'll try to recreate the issue locally. What OS is it running on? We have a lot of sites running on 2.1.3, and nobody else has reported anything similar to this.

-- GeorgeClark - 07 May 2017

Thank you!

This is part of lighttpd config that sets up wikis:
# normalize host name
$HTTP["host"] != "www.mydomain.com" {
  $HTTP["scheme"] == "https" {
    url.redirect = ( "^/(.*)" => "https://www.mydomain.com/$1" )
  } else $HTTP["scheme"] == "http" {
    url.redirect = ( "^/(.*)" => "http://www.mydomain.com/$1" )
  }
}

# redirect all protected urls to SSL host
$HTTP["scheme"] == "http" {
  $HTTP["url"] =~ "^/(bzr|mail|mailman|redmine|svn|wiki)(/|$)" {
    url.redirect = ( "^/(.*)" => "https://www.mydomain.com/$1" )
  }
}

# Require executable bit on CGI scripts
cgi.execute-x-only = "enable"

# SSL host
$SERVER["socket"] == ":443" {
  ssl.pemfile = "/etc/letsencrypt.sh/certs/mydomain.com.pem"
  ssl.engine  = "enable"

  #####################################################################
  # Wiki
#  $HTTP["url"] =~ "^/wiki2?/bin/configure" {
#    alias.url += ( "/wiki/bin" => "/myfiles/wiki/bin", "/wiki2/bin" => "/myfiles/wiki2/bin" )
#    cgi.assign = ( "" => "" )
#    # using mod_auth patch from http://redmine.lighttpd.net/issues/1985
#    auth.backend = "program"
#    auth.backend.program.exec = "/myfiles/bin/webauth.sh"
#    auth.require = ( "" => (
#      "method" => "basic",
#      "realm" => "Foswiki Configuration",
#      "require" => "valid-user"
#    ))
#  }

  $HTTP["url"] =~ "^/wiki2?/bin" { cgi.assign = ( "" => "" ) }
  # static files
  alias.url += ( "/wiki2" => "/myfiles/wiki2/", "/wiki" => "/myfiles/wiki/" )
  url.rewrite-once += ( "^/wiki/e/([A-Z_].*)" => "/wiki/bin/edit/$1",
     "^/wiki/([?A-Z_].*)" => "/wiki/bin/view/$1",
     "^/wiki/pub/System/(.*)" => "/wiki/pub/System/$1",
     "^/wiki/pub/(.*?)/([^/?]+)(?:\?(.*))?$" => "/wiki/bin/viewfile/$1?filename=$2;$3" )
  url.rewrite-repeat = ( "^/wiki/?(index.*)?$" => "/wiki/Main" )
  $HTTP["url"] =~ "^/wiki.?/(data|templates|lib|locale|tools|working)" {
    url.access-deny = ("")
  }
  $HTTP["url"] =~ "^/wiki" {
    $HTTP["useragent"] =~ "BecomeBot|Charlotte/|Jakarta|MSIECrawler|VoilaBot|www\.netforex\.org|^($|Accoona|ActiveAgent|Attache|ConveraCrawler|CrownPeak-HttpAgent|EmailCollector|EmailSiphon|Exabot|FAST|FDM|GetRight/6.0a|GetWebPics|Gigabot|Google\sSpider|IRLbot|Java|KrakSpider|LeechGet|LinkWalker|Lsearch|MJ12bot|MSRBOT|Microsoft|NutchCVS|RealDownload|Rome|Roverbot|Seekbot|SiteSnagger|SiteSucker|Snapbot|SpiderKU|SpiderMan|Squid|Teleport|User-Agent\:|WX_mail|WebCopier|WebDevil|WebSec|WebVac|Web\sDownloader|Webwhacker|Webzip|Wells|WhoWhere|ZIBB|bot|e-SocietyRobot|gonzo1|iGetter|ichiro|ie_crawler|larbin|noxtrumbot|schibstedsokbot|sogou|voyager|w3search|yacybot)" {
      url.access-deny = ("")
    }
  }

}

I have commented out the part that uses non-standard authentication backend for additional protection of the configure script - it should not affect the login/view operation anyway.

I am on CentOS6, this is the list of installed perl packages:
perl-5.10.1-144.el6.x86_64
perl-Archive-Tar-1.58-144.el6.x86_64
perl-CGI-3.51-144.el6.x86_64
perl-CGI-Session-4.35-6.el6.noarch
perl-Compress-Raw-Zlib-2.021-144.el6.x86_64
perl-Compress-Zlib-2.021-144.el6.x86_64
perl-Crypt-OpenSSL-Bignum-0.04-8.1.el6.x86_64
perl-Crypt-OpenSSL-Random-0.04-9.1.el6.x86_64
perl-Crypt-OpenSSL-RSA-0.25-10.1.el6.x86_64
perl-Crypt-PasswdMD5-1.3-6.el6.noarch
perl-DBD-MySQL-4.013-3.el6.x86_64
perl-DBD-Pg-2.15.1-4.el6_3.x86_64
perl-DBI-1.609-4.el6.x86_64
perl-devel-5.10.1-144.el6.x86_64
perl-Digest-HMAC-1.01-22.el6.noarch
perl-Digest-SHA1-2.12-2.el6.x86_64
perl-Digest-SHA-5.47-144.el6.x86_64
perl-Email-Address-1.905-1.el6.noarch
perl-Email-MessageID-1.401-4.el6.noarch
perl-Email-MIME-1.906-2.el6.noarch
perl-Email-MIME-ContentType-1.015-2.el6.noarch
perl-Email-MIME-Encodings-1.313-2.el6.noarch
perl-Email-Simple-2.100-1.el6.noarch
perl-Encode-Detect-1.01-2.el6.x86_64
perl-Error-0.17015-4.el6.noarch
perl-ExtUtils-MakeMaker-6.55-144.el6.x86_64
perl-ExtUtils-ParseXS-2.2003.0-144.el6.x86_64
perl-FCGI-0.71-4.el6.x86_64
perl-File-Copy-Recursive-0.38-4.el6.noarch
perl-FreezeThaw-0.45-5.el6.noarch
perl-GD-2.44-3.el6.x86_64
perl-HTML-Parser-3.64-2.el6.x86_64
perl-HTML-Tagset-3.20-4.el6.noarch
perl-HTML-Tree-3.23-10.el6.noarch
perl-IO-Compress-Base-2.021-144.el6.x86_64
perl-IO-Compress-Zlib-2.021-144.el6.x86_64
perl-IO-Socket-INET6-2.56-4.el6.noarch
perl-IO-Socket-SSL-1.31-3.el6_8.2.noarch
perl-IO-Zlib-1.09-144.el6.x86_64
perl-JSON-2.15-5.el6.noarch
perl-libs-5.10.1-144.el6.x86_64
perl-libwww-perl-5.833-5.el6.noarch
perl-Mail-DKIM-0.37-2.el6.noarch
perl-MailTools-2.04-4.el6.noarch
perl-MIME-Types-1.28-2.el6.noarch
perl-Module-Pluggable-3.90-144.el6.x86_64
perl-NetAddr-IP-4.027-7.el6.x86_64
perl-Net-DNS-0.65-5.el6.x86_64
perl-Net-LibIDN-0.12-3.el6.x86_64
perl-Net-SSLeay-1.35-10.el6_8.1.x86_64
perl-Package-Constants-0.02-144.el6.x86_64
perl-Pod-Escapes-1.04-144.el6.x86_64
perl-Pod-Simple-3.13-144.el6.x86_64
perl-Socket6-0.23-4.el6.x86_64
perl-Taint-Runtime-0.03-9.el6.x86_64
perl-Test-Harness-3.17-144.el6.x86_64
perl-Test-Simple-0.92-144.el6.x86_64
perl-TimeDate-1.16-13.el6.noarch
perl-Time-HiRes-1.9721-144.el6.x86_64
perl-URI-1.40-2.el6.noarch
perl-version-0.77-144.el6.x86_64

-- AlexanderSmishlajev - 08 May 2017

A couple of observations as I read through the config:
  • Protecting configure won't fully work on 2.x. The bulk of the work is actually done by bin/jsonrpc. bin/configure just puts up a static page and loads javascript for javascript interface.
  • The "Redirect all protected" clause only handles wiki, not wiki2
  • I don't believe aggressive URL shortening like "^/wiki/e/([A-Z_].*)" => "/wiki/bin/edit/$1", will work with Foswiki 2.x without perl changes. The scripts recover the "Action" from the URL rather than hardcode it like Foswiki 1.x did.
  • Any Webs named with utf-8 characters are not going to work due to [A-Z_] matching. For ex, a web named Über.
  • A lot of the other rewrite rules are specific to wiki, not wiki2. Don't know if that's any impact though.
It will take me a bit to get this set up. I'll report as I make progress.

-- GeorgeClark - 08 May 2017

Works here for me. I installed the latest Centos into a VM. Installed lighttpd and the modules listed in SystemRequirements. Took me quite a while to get past selinux, but I was able to bootstrap a new configuration, Register a user, and then log out & in without issues.
$HTTP["host"] != "centos.mydomain.com" {
  $HTTP["scheme"] == "https" {
    url.redirect = ( "^/(.*)" => "https://centos.mydomain.com/$1" )
  } else $HTTP["scheme"] == "http" {
    url.redirect = ( "^/(.*)" => "http://centos.mydomain.com/$1" )
  }
}

#debug.log-request-handling        = "enable"
#debug.log-request-header          = "enable"
#debug.log-request-header-on-error = "enable"
#debug.log-response-header         = "enable"
#debug.log-file-not-found          = "enable"
#debug.log-condition-handling      = "enable"

# Set the ENV variable for the path.
setenv.add-environment = ("PATH" => env.PATH )

# redirect all protected urls to SSL host
#$HTTP["scheme"] == "http" {
#  $HTTP["url"] =~ "^/(bzr|mail|mailman|redmine|svn|wiki|wiki2)(/|$)" {
#    url.redirect = ( "^/(.*)" => "https://www.mydomain.com/$1" )
#  }
#}

# Require executable bit on CGI scripts
cgi.execute-x-only = "enable"

# SSL host
#$SERVER["socket"] == ":443" {
#  ssl.pemfile = "/etc/letsencrypt.sh/certs/mydomain.com.pem"
#  ssl.engine  = "enable"

  #####################################################################
  # Wiki

  $HTTP["url"] =~ "^/wiki2?/bin" { cgi.assign = ( "" => "/usr/bin/perl" ) }

  # static files
  alias.url += ( "/wiki2" => "/var/www/wiki2/", "/wiki" => "/var/www/wiki/" )
  url.rewrite-once += ( "^/wiki/e/([A-Z_].*)" => "/wiki/bin/edit/$1",
     "^/wiki2/([?A-Z_].*)" => "/wiki2/bin/view/$1",
     "^/wiki2/pub/System/(.*)" => "/wiki2/pub/System/$1",
     "^/wiki2/pub/(.*?)/([^/?]+)(?:\?(.*))?$" => "/wiki2/bin/viewfile/$1?filename=$2;$3" )
  url.rewrite-repeat = ( "^/wiki2/?(index.*)?$" => "/wiki2/Main" )
  $HTTP["url"] =~ "^/wiki2.?/(data|templates|lib|locale|tools|working)" {
    url.access-deny = ("")
  }
  $HTTP["url"] =~ "^/wiki2" {
    $HTTP["useragent"] =~ "BecomeBot|Charlotte/|Jakarta|MSIECrawler|VoilaBot|www\.netforex\.org|^($|Accoona|ActiveAgent|Attache|ConveraCrawler|CrownPeak-HttpAgent|EmailCollector|EmailSiphon|Exabot|FAST|FDM|GetRight/6.0a|GetWebPics|Gigabot|Google\sSpider|IRLbot|Java|KrakSpider|LeechGet|LinkWalker|Lsearch|MJ12bot|MSRBOT|Microsoft|NutchCVS|RealDownload|Rome|Roverbot|Seekbot|SiteSnagger|SiteSucker|Snapbot|SpiderKU|SpiderMan|Squid|Teleport|User-Agent\:|WX_mail|WebCopier|WebDevil|WebSec|WebVac|Web\sDownloader|Webwhacker|Webzip|Wells|WhoWhere|ZIBB|bot|e-SocietyRobot|gonzo1|iGetter|ichiro|ie_crawler|larbin|noxtrumbot|schibstedsokbot|sogou|voyager|w3search|yacybot)" {
      url.access-deny = ("")
    }
  }

I changed a couple of paths, commented out SSL for now, added a Set for the PATH environment.

-- GeorgeClark - 09 May 2017

Found it! See https://tools.ietf.org/html/rfc3875#section-6.2.2

The TemplateLogin->login method redirects to what by CGI specs is called local-Location. According to RFC 3875, in this case The script MUST NOT return any other header fields or a message-body, and the server MUST generate the response that it would have produced in response to a request containing the URL

scheme "://" server-name ":" server-port local-pathquery

In other words, setting a cookie without giving full redirect URL is violation of CGI protocol. If I add $query->url(base => 1, full => 1) to $origurl in the TemplateLogin->login, everything works as expected.

-- AlexanderSmishlajev - 09 May 2017

Thank you for finding the solution. I'm really amazed that nobody else has run into this. We'll look into a code change for 2.1.4. Do you have any insight as to why only your installation has run into this?

-- GeorgeClark - 09 May 2017

Any chance you could post a diff of your change? Thanks. I wonder if this is related to a specific lighttpd version. You're running 1.4.41, I have two systems, 1.4.35 and 1.4.45.

-- GeorgeClark - 09 May 2017

What I did is this:
--- Foswiki-2.1.3/lib/Foswiki/LoginManager/TemplateLogin.pm.orig   2017-02-12 23:59:40.000000000 +0200
+++ Foswiki-2.1.3/lib/Foswiki/LoginManager/TemplateLogin.pm   2017-05-09 19:32:19.000000000 +0300
@@ -260,10 +260,11 @@
                 $query->action($origaction) if $origaction;
             }
 
+            my $base = $query->url(base => 1, full => 1);
             # Restore the method used on origUrl so if it was a GET, we
             # get another GET.
             $query->method($origmethod);
-            $session->redirect( $origurl, 1 );
+            $session->redirect( $base . $origurl, 1 );
             return;
         }
         else {

but it was just a quick check to see if I found a culprit. I think there should be URL composition API to do things like that.

Besides, there are many more redirects in the system. Perhaps they all need to be examined. For example, I see cookies added to redirect in Foswiki.pm line 1314.

As for specific lighttpd version - I have no idea. As far as I understand, the thing is disabled by default in version 1.4.46 with new option cgi.local-redir (see https://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_ModCGI), but prior to that I do not see it mentioned in release anouncements.

By the way, regarding your comment on aggressive URL shortening like "^/wiki/e/([A-Z_].*)" => "/wiki/bin/edit/$1", - I have found that all executable scripts use __FILE__ for action name. URL paths should be of no importance.

Thanks again for your assistance.

-- AlexanderSmishlajev - 10 May 2017

If you could try the following patch, I think this is the correct place to fix the issue and would cover all redirects wherever generated:

diff --git a/core/lib/Foswiki/Response.pm b/core/lib/Foswiki/Response.pm
index 5a93329..a5b0461 100644
--- a/core/lib/Foswiki/Response.pm
+++ b/core/lib/Foswiki/Response.pm
@@ -410,6 +410,13 @@ sub redirect {
     ) if DEBUG;
     return if ( $status && $status !~ /^\s*3\d\d.*/ );
 
+    # Per https://tools.ietf.org/html/rfc3875#section-6.2.2, the server MUST NOT
+    # provide any other headers for local redirects such as cookies. So make sure
+    # the location is an absolute location.
+    unless ( $url =~ m{^https?://}i ) {
+       $url = $Foswiki::cfg{DefaultUrlHost} . $url;
+       }
+
     my @headers = ( -Location => $url );
     push @headers, '-Status' => $status;
     push @headers, '-Cookie' => $cookies if $cookies;

Regarding the URL shortening, Certain configurations, mod_perl and fcgi, do not use the executable scripts, so there is no FILE location to reference.

-- GeorgeClark - 10 May 2017

Yes, your patch helps. Thank you!

-- AlexanderSmishlajev - 11 May 2017
 

QuestionForm edit

Subject Installation of Foswiki, Authentication or Authorisation
Extension
Version Foswiki 2.1.3
Status Task filed
Related Topics Tasks.Item14396
Topic revision: r34 - 11 May 2017, AlexanderSmishlajev
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