Item982: Expired session cookies preventing logins.

IRC discussion to date has revealed that this effects at least Safari and Firefox 3 on Mac OS 10.5.x. When a session expires, the user cannot log back into Foswiki without manually deleting the cookie from within their browser - the correct name/password combo won't work.

Is this related to Task.Item873? At least one IRC user tried the fix mentioned there, but the problem persisted.

-- AaronFuleki - 04 Feb 2009

Is this with TemplateLogin or ApacheLogin? And have you tried both?

Can you confirm it also on a Windows client?

Can you give the relevant configure settings?

This sounds pretty serious to me.

-- KennethLavrsen - 06 Feb 2009

I don't see a problem with Template login on Safari.

-- ArthurClemens - 07 Feb 2009

I've now seen this on all three of the development installs I'm working on: FW1.0.0 on a Centos 5.2 VM (LDAP auth), FW1.0.0 on Debian Etch (Template Login), and trunk rev 2419 on Fedora Core 9 (LDAP Auth, different server). TWiki installs, sometimes on the same box with nearly identical configs, do not exhibit this issue.

Quitting Safari doesn't fix it - I have to delete the session cookie before authentication succeeds. I don't use windows machines regularly, but I can boot up a VM and try it. I can post full configs if anyone's interested, but I'm not yet sure which parts would be relevant.

-- AaronFuleki - 11 Feb 2009

We do need your configure settings (LocalSite.cfg). Just post the lot. Remember to distort passwords, emails and other private data. We especially need to understand how the Security Setup, Store Settings and all plugins installed we need to understand.

How is the LDAP auth done? LdapContrib or simple mod_ldap?

We need to be able to reproduce this to fix it.

-- KennethLavrsen - 11 Feb 2009

So last night I booted up my trusty XP VM, and logged into my FW1.0.0/Centos 5.2/LdapContrib instance in IE6, Safari 3, and Firefox 3. Just now I went back, clicked refresh, and typed in my known, working LDAP creds into each browser. They all three replied with an infinite number of login prompts, outputting this to the apache error logs thrice each request:

[Wed Feb 11 11:27:46 2009] [error] [client XXX.XXX.XXX.XXX] [Wed Feb 11 11:27:46 2009] login: Use of uninitialized value in string eq at /usr/local/htdocs/Foswiki-1.0.0/lib/Foswiki/LoginManager/Session.pm line 42., referer: https://wiki.domain.tld/foswiki/bin/login/Main/WebHome?web=Main;topic=WebHome;action=;origurl=/foswiki/bin/view/Main/WebHome%3ffoswiki_redirect_cache%3d3b89c0ca965c2a35d75014ce34bdf200

Deleting the cookie allowed logins in all browsers, with no error message from apache. Here's the config, along with another instance showing this behavior.

• badcookie_FW1.cfg: Config from an otherwise working FW1.0.0 install, where expired sessions tend prevent login, until the cookie is deleted.
• badcookie_svn2419.cfg: Config from an otherwise working FW svn install, where expired sessions tend prevent login, until the cookie is deleted.

I noticed that {Sessions}{ExpireCookiesAfter} is set to 0. Could that have anything to do with it?

-- AaronFuleki - 11 Feb 2009

{Sessions}{ExpireCookiesAfter} set to 0 is the normal case and should tell the browser that the cookie is to be forgotten when you close the browser.

I have tried to duplicate this bug. I set the expiry time to two minutes to easily reproduce this.

And I cannot.

I see a number of possibilitities

• Both your configurations use LdapContrib. This is my main suspect. I cannot test with that as I do not have an Ldap server here I can test with.
• You may also have missed to patch Foswiki 1.0.0 as described in KnownIssuesOfFoswiki01x00 which is directly related to sessions. See also Item873.

I will for now change the attribute to be LdapContrib because that is the most likely scenario.

Aaron can you reproduce this on a Foswiki without LdapContrib with passwords in a normal .htpasswd file?

Aaron can you also confirm that you have patched Foswiki for the 873 bug?

MichaelDaum do you have time to look at LdapContrib for possible problem?

-- KennethLavrsen - 13 Feb 2009

Aaron can you reproduce this on a Foswiki without LdapContrib with passwords in a normal .htpasswd file?

Yes. One of my three installs is running on straight-up TemplateLogin/.htpasswd - so, at least for me, this effects more than LdapContrib.

I'll try the Item873 patch.

-- AaronFuleki - 17 Feb 2009

Aron, please give us a bit more info about your system:

• Which version of CGI and CGI::Session is installed on your system
• Which web server are you using?
• Which browser are you using?
• Which LDAP directory are you using?
• Are there any non-latin1 chars in your user name or your credentials?

I ask this because I want to know why the following lines of code error out on your system.

Line 42 in Foswiki::LoginManager::Session says

sub _ip_matches {
    return ( $_[0]->{_DATA}->{_SESSION_REMOTE_ADDR} eq
          $_[0]->query->remoteAddress );
}

at least on my system. Is that the same on yours? So question is: why is Foswiki unable to get your remote address?

Next, please give us a step-by-step instruction how to reproduce the error. I am using an LDAP & Foswiki setup very similar to yours. I can't see anything special, except your use of TLS. Try to disable TLS.

For now, I tried to login and out repeatedly, deleted the session cookie, removed the cgisession object and logged in and out again using LdapContrib + TemplateLogin. I've set the session expiry time to a low value, logged in using two independent browses thus creating two session objects at the backend. I used the second browser to expire the session object of the first. I then used the first browser to log in again successfully after its session object has been deleted on the backend.

This all seems to work as expected so ...

-- MichaelDaum - 17 Feb 2009

I'm experiencing the same problem with Foswiki::LoginManager::Session. I'm using TemplateLogin and have performed the patch in Item873 but this did not make a difference. I have some odd session files in the working/tmp directory. For example:

$D = {'_SESSION_ID' => '2d4bb67d926d6578cce514a78b8c05cb',
      '_SESSION_ATIME' => 1235557118,
      'REMEMBER' => undef,
      '_SESSION_CTIME' => 1235557118};;$D

There's no AUTHUSER and no _SESSION_REMOTE_ADDRESS in there, so Session.pm wil return NULL. I have Foswiki installed on a FreeBSD 6.1 server with CGI v3.15, CGI:Cookie v1.26 and CGI::Session v4.20. I use IE7 as a browser.

-- MaartenKallen - 25 Feb 2009

Can you check the logs for the same session? I mean, normally the remote address should be printed in the logs:

| 2009-02-24T12:28:47Z info | User | action | Web.WebTopic | (not exist) | Remote Address |

This is with 1.0.2 (with the new logging format). The old one should look like this:

| 22 Feb 2009 - 19:54 | User | action | Web.Topic |  | Remote Address |

-- OlivierRaginel - 26 Feb 2009

Based on the timestamp in the example above, I find two entries at 11:18 on February 25, 2009:

| 25 Feb 2009 - 11:18 | JanJanssen | attach | Tools.WikiHandleiding |  | 194.151.101.4 |
| 25 Feb 2009 - 11:18 | JanJanssen | attach | Tools.WikiHandleiding | aanmeldenleverancier2.jpg | 194.151.101.4 |

In general, I see no missing IP addresses in the log. However, immediately after these two entries I see the following entries:

| 25 Feb 2009 - 11:19 | guest | view | Main.WebHome |  Mozilla | 194.151.101.12 |
| 25 Feb 2009 - 11:19 | guest | view | Tools.WebHome |  Mozilla | 194.151.101.12 |
| 25 Feb 2009 - 11:20 | guest | view | Tools.WikiHandleiding |  Mozilla | 194.151.101.12 |

I'm pretty sure this is the same user who lost his session while trying to save to the wiki. See the different IP address? Could there be a problem with dynamic IP's?

-- MaartenKallen - 26 Feb 2009

If the same user changed IP address then it is correct that this goofs up the whole thing.

I have also noticed that the same person with new IP cannot re-authenticate until the session is wiped out or cookie deleted. Which normally requires to close the browser and open it again.

You need to disable the session and IP matching in configure if your users can change IP address on the fly

We never heard this before but suddenly people start having the problem. I have the feeling there are some new proxy software released and getting installed around the world that creates this issue.

-- KennethLavrsen - 26 Feb 2009

This seems to be related to Item1028. So the solution is to disable (manually, I didn't see any possibility to do this in the configure script) IP matching in the LocalSite.cfg file. I'll test if this works...

-- MaartenKallen - 26 Feb 2009

None of my problem systems use proxies, or dynamic IP addresses (one network uses dynamic IPs, but they actually don't change - long story). Not sure how that changes anything.

I'll try to reproduce again, and look at the log information as described above.

-- AaronFuleki - 26 Feb 2009

If you have an old version of CGI::Session, you might want to check Item1306. Basically, version below 3.30 of CGI::Session had this bug, so either upgrade Foswiki and use the one provided in 1.0.4, or upgrade your local copy.

If this works, thanks to close this bug.

-- OlivierRaginel - 19 Mar 2009