This isn’t very compatible with IPv6. Especially if privacy address extensions are enabled which they are by default on windows. Your IP changes all the time and the session invalidates itself. At least there is a hidden tweak to disable this behavior though, but I’m thinking it shouldn’t be hidden.
i don’t have ipv6 but maybe in this case a subset of an address should be stored and compared, i.e. your subnet.
ipv4 check can also be limited to first octets although i don’t think it would be useful / secure enough.
another solution is geoip but again limited usability.
e: until better solution is found REMOTE_ADDR checking could be disabled for ipv6 altogether, i suppose
I see your point of securing things and this works for a stable work environment, but I am roaming between Wifi networks all day with my laptop and I don’t think I am the only one who would rather take this as disabled by default .
I am on PHP 7.0.30-0+deb9u1 and my config
define('_SKIP_SESSION_ADDRESS_CHECKS', true)
// skip IP address validation
breaks tt-rss, only loads blank page, no further requests are made.
e: has to be
define('_SKIP_SESSION_ADDRESS_CHECKS', true);
// skip IP address validation
i think you forgot the comma at the end
yes you are right, thanks!
I’m not even sure subnet will help. If I tether to my mobile I get an IPv6 address which is a /64, if I drop the connection and reconnect I’ll get another /64, but not necessarily from the same /48 as the mobile network has a /32 to allocate from in total.
Similarly as soon as I get home and connect to my own wifi it will get a totally different /64 from another /48.
The other issue is browsers do “Happy Eyeballs” where they will either use IPv4 or IPv6 depending on which one responds the quickest. So whilst most of the time v6 will win, it’s possible the IP will change between v4 and v6.
Admittedly I guess you are not expecting people to set long cookie session lifetimes, I set mine to about a year so it always stays logged in. But with this change my session is being invalidated every time my laptop boots up. For now I’ve disabled it with the config tweak.
oh i do. i also have static IP addresses, pretty much everywhere. which is, uh, uncommon i guess.
e.g my personal use case:
Home: IPv4 + IPv6 dual-stack, changing IPs at least every 24h, most of the times default config here.
Work: static IPv4, never changing over years
On the road, mobile tethering: so many IP changes (v4 and sometimes v6) when moving, thanks to this bad provider…
I’d say it’s not a very practical solution anymore to restrict to IP addresses for most people.
So I like it disabled by default and people wanting more security can enable it.
yeah, i suppose this makes sense, i’ll rework this to be opt-in.
e: or moved out to a possible plugin.
e2: removed for now
e3: i’m still not satisfied with the current session ID solution so i’m going to poke around at it some more, luckily i have php 5.6 test box now.
as a followup on yesterdays issue, i think i finally managed to figure out what was wrong and it looks like an obscure bug with tt-rss ancient custom session handling code, which apparently only manifested itself if session id regeneration was used on php 5.6 (looks like php 7 has a slightly different behavior and doesn’t trigger it).
e: i’m sure nobody cares but i’ll elaborate anyway because autism compels me to:
this is a custom handler which tt-rss uses to store session data in the database. it’s called automatically before PHP interpreter exits after generating the page:
function ttrss_write ($id, $data) {
global $session_expire;
$data = base64_encode($data);
$expire = time() + $session_expire;
$sth = Db::pdo()->prepare("UPDATE ttrss_sessions SET data=?, expire=? WHERE id=?");
$sth->execute([$data, $expire, $id]);
return true;
}
note how it’s assumed that session already exists when its data is being written (there’s no INSERT, only UPDATE), which how this always works. unless you regenerate session ID on the fly, after creating it.
which is why this handler fails silently after logging in without saving anything which is why you get redirected back to the login form with no visible errors.
i guess PHP 7 is smart enough to call the read handler after changing the ID (it’s technically a new session, this makes sense) which initializes the database which is why this worked as intended for me.
it took me two days to figure it out. duh.
Updated my install this morning, can confirm I am no longer experiencing the issue.
Thanks fox!