 |
|
You are here: Foswiki>Support Web>SupportQuestions>Question1873 (11 May 2017, AlexanderSmishlajev)Edit Attach
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 authenticatedWhat 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]
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.
- 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.
$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 |
$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/WebHomeThe 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.
$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-pathqueryIn 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 |
Edit | Attach | Print version | History: r34 < r33 < r32 < r31 | Backlinks | View wiki text | Edit wiki text | More topic actions
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. 
Legal Imprint Privacy Policy
Legal Imprint Privacy Policy