Partial fix Sessions invalidate if IP changes

digitalpoint

Well-known member
Affected version
2.0.7
If you start the user registration process on one IP, then finish it on another (like if you go on/off wifi), the registration fails and redirects you to an empty registration page (not only does it fail, you lose everything you entered).
 
Ended up running into what I suspect is the same issue issue of the session being bound to your IP. Every time your IP changes, you get logged out of admin area. It’s rather obnoxious when you have a crappy Wi-Fi connection and your device is waivering between Wi-Fi and cellular.
 
I haven't tried this myself but I think you could try to change ipv4CidrMatch and/or ipv6CidrMatch to 0 in XF/Session/Session.php.

Maybe that should be the default for HTTPS-enabled sites?
 
If you start the user registration process on one IP, then finish it on another (like if you go on/off wifi), the registration fails and redirects you to an empty registration page (not only does it fail, you lose everything you entered).
I opened a potentially related registration bug https://xenforo.com/community/threa...ue-to-starttime-check-in-registerform.150926/ that is affecting a large percentage of our users.

Is there a valid suggested solution for this? Does the ipv4CidrMatch change above solve theproblem?
 
I opened a potentially related registration bug https://xenforo.com/community/threa...ue-to-starttime-check-in-registerform.150926/ that is affecting a large percentage of our users.

Is there a valid suggested solution for this? Does the ipv4CidrMatch change above solve theproblem?
Some feedback: We set both the v4 & v6 values to zero and the failed registrations have gone away.

this is a significant issue for our users as a quick peak at the IP Addresses of new very low traffic members indicate a handful of users have more than 1 IP address being recorded within the same minute. The IP addresses appear to be google proxy stuff along with a large handful of IPs associated with the same local telco.

I have no idea why multiple IP addresses are being utilized by the users in such a short period of time.
 
Just wanted to offer an alternative to editing the core code directly if you need to use this as a workaround. Instead, you can actually make the changes by editing your config.php file and extending the session container:
PHP:
$c->extend('session', function(\XF\Session\Session $session)
{
   $session->setConfig([
        'ipv4CidrMatch' => 0,
        'ipv6CidrMatch' => 0
    ]);
   return $session;
});
 
Last edited:
@digitalpoint this behaviour is very much as designed as a security measure in case a session_id is somehow stolen.

We wouldn't be looking to make any changes here, though if you wanted to opt out of such a measure, especially if working on a test/development server, then the above code added to config.php would be the answer.

However, we wouldn't recommend opting out on a live server.
 
@giffenk this does not affect your bug report. We will still be looking into that as we should have code that surfaces the real IP address from some proxy servers a user might be using.
 
@digitalpoint this behaviour is very much as designed as a security measure in case a session_id is somehow stolen.

We wouldn't be looking to make any changes here, though if you wanted to opt out of such a measure, especially if working on a test/development server, then the above code added to config.php would be the answer.

However, we wouldn't recommend opting out on a live server.
Well at least there is an option to disable it via config.php...

The biggest issue I've been running into is an end-user support thing. A user going through a fairly extensive registration application in our case, waivers between wifi and cellular during the registration process and boom, they just lost everything they entered on the registration page. What if the CIDR matching didn't apply to guest sessions? Are we really worried about a session_id being stolen for a non-logged in user? How would one even *be* stolen in a real-world scenario besides a man in the middle attack (if they are in the middle, they could also spoof being on the same CIDR)?

I'm all for security, but this particular thing has become a support issue with 3 different users trying to register on a site that has 228 registered users. In the real-world it's definitely happened to me as well when it logs me out of the admin area when I go between cell/wifi, but at least that's a staff thing and doesn't (usually) involve a ton of lost data like our registration/application for the site.
 
We'll consider restricting it to members only.

Worth noting, however, that this isn't a new behaviour or anything. Sessions have been invalidated by IP changes since XF 1.0. That likely would have started affecting registrations circa 1.1.4 when we started storing a registration token in the session.

I don't particularly recall a specific bug report or troubleshooting request in all of that time, so it's certainly interesting we got essentially two reports of it in such close proximity :)
 
Well in my case it was probably less of a burden for users when it did happen since my XF sites were all a quick username/email/password registration, so they probably never bothered to say anything if they had to redo it real quick.

The site that it raised the issue for me is my first XF2 site... which is a close knit group of people (you need to be invited just to register), and the registration process is a LOT of things being asked (and required), so in this particular case it's a substantial amount of info/work that went into the registration that gets lost *and* being an invite-only site, the prospective registrant also has a direct line to someone to complain about it to (as in they text me). Just to give an idea of how annoying it is for users, there are 18 fields they need to fill out for this particular registration, about half of which are narratives/paragraphs.

It's an invite-only "secret society". lol https://reliquarysociety.com/
 
Top Bottom