Item2002: When changing IP (road warriors) logging in results in an endless loop of login screens

I have seen that when I move my laptop from the office to home or any other location, i cannot log in to my recently upgraded foswiki instance anymore.

When i get the first login dialog (either by clicking log-in, going to a protected topic or hitting 'edit'), i enter the correct details. Then I get the login dialog again, without a message telling me why i'm not logged in. Entering the details again and logging in results in yet another dialog, etc..

This only seems to happen when i'm logged in, and then move the laptop to another network (and thus another IP).

I want to try and reproduce this in a test setup, to make it easier to switch IP's.

-- KoenMartens - 03 Sep 2009

Did you enable the $Foswiki::cfg{Sessions}{UseIPMatching}?

We changed this to default off some time ago because it causes too much trouble. People do not have static IPs through a session anymore in many normal contexts (mobile, wireless roaming, proxies etc).

-- KennethLavrsen - 03 Sep 2009

See also Item1306

Are you testing on a 1.0.6?

Do you have a CGI::Session installed which is older than the one shipped with Foswiki? It would be used then and could be your problem.

-- KennethLavrsen

I have seen a similar issue in 1.0.6 (when I reproduce it I may open a seperate task, depending on findings)

When I edit the same topic (sequentially, no lease issues) on 2 seperate computers, logged in as the same user, one user's edits are lost to the CSRF warning dialog. Clicking OK doesn't help, it steadfastly seems to refuse to let the second computer's session save.

if this turns out to be the same issue, then I recon this is urgent.

-- SvenDowideit - 05 Sep 2009

I tried the primitive way of reproducing that I also used in Item1306

• Edit some topic, and keep the screen in edit mode.
• Hack the session file on the server changing the IP address to something else. This simulates that the session file was created by another IP address.
• Save the topic

And this primitive test shows that thing work

• If {Sessions}{UseIPMatching} is enabled the CSRF dialog is shown. When I confirm with an OK I am allowed to save. I am using ApacheLogin so the browser would re-authenticate without me knowing so I assume this is OK behaviour.
• If {Sessions}{UseIPMatching} is disabled the save happens without notice
• In both cases the content is correctly saved

I did these tests in the Release branch and not with the now old 1.0.6 so the problem could be fixed by now.

Note that {Sessions}{UseIPMatching} disabled is the default, but if you run a pseudo-install or your installation is an upgrade from before 1.0.6 days you will have it enabled by default and need to disable it in configure. We still need to hear Koen's answer to this.

I need to repeat my tests with Template Login. That could be broken as the authentication is quite different.

-- KennethLavrsen - 06 Sep 2009

I have indeed enabled UseIPMatching:

$Foswiki::cfg{Sessions}{UseIPMatching} = 1;

This is default from configure, this is an old TWiki instance I upgraded by installing a fresh new foswiki 1.0.6 tarball and moving the old TWiki webs over.

I probably did have a CGI::Session that was older than the one shipped with 1.0.6, as the particular jail i was running this in was hopelessly out of date. Recently, I upgraded all ports in that jail, including CGI::Session. Haven't seen the issue since, but will do some further testing.

-- KoenMartens - 13 Sep 2009

Ok, it seems this is solved by upgrading the perl modules on that system. I've just tested login in, then changing my browser to use a socks proxy via an ssh connection to another host, effectively changing my ip. I hit edit, get a login dialog, log in, and can edit. No more endless login dialogs.

-- KoenMartens - 13 Sep 2009

I am closing this with no action then.

-- KennethLavrsen - 13 Sep 2009

Except that we could try to show an alert if the required perl modules are not in place.

-- ArthurClemens - 13 Sep 2009