4 ms·

i worked at a company that spent 6 months and 2 devs to solve a huge infrastructure change without logging anyone out of their session

dahart 6y ago
Isn't that a tad different than discovering an active security hole?
2ion 6y ago
Logging people out seems like a hella low price to pay to pay for a potential security issue. Of course, hats off if you hold your engineering organization to such a high standard for normal changes.
- kazinator 6y ago
  Not logging anyone out while upgrading the kernel of a time-sharing operating system: nice feat. Not logging anyone out while updating a suite of REST-ful applications: ho hum.
- foolfoolz 6y ago
  this was stupid. we were not a big enough org to spend 2 people like this. i never understood why forcing people to log in again was so controversial
aeyes 6y ago
Depends on the type of application, 99.9% of Wikimedia users are using the site without being logged in. If the site doesn't work without being logged in you could frustrate users and they might just use a different product instead of searching for their login after being logged in for a year or longer.
kazinator 6y ago
That doesn't seem difficult; just don't change the format of the session tokens. Eg a web application: you can substantially rewrite a web application, without invalidating logged in sessions. The point here is that the logged in sessions were suspected of being unauthorized. The unauthorized sessions had to be turfed, and the clearest way of being sure that all unauthorized sessions are turfed is to delete all the sessions. Of course, some those with unauthorized access will also try to log in to resume that unauthorized access, but presumably there is some trap laid for that. Maybe for the accounts suspected of having been breached, there will be a mandatory password recovery procedure or whatever. Or they will monitor for suspicious logins from different IP addresses.
- pvg 6y ago
  You can have state sitting in (serverside) session storage that is incompatible with the new version but you don't want users to lose. So now you have to migrate it, which can end up being actual work depending on the change.

dahart 6y ago

Isn't that a tad different than discovering an active security hole?

2ion 6y ago

Logging people out seems like a hella low price to pay to pay for a potential security issue. Of course, hats off if you hold your engineering organization to such a high standard for normal changes.

kazinator 6y ago
Not logging anyone out while upgrading the kernel of a time-sharing operating system: nice feat. Not logging anyone out while updating a suite of REST-ful applications: ho hum.
foolfoolz 6y ago
this was stupid. we were not a big enough org to spend 2 people like this. i never understood why forcing people to log in again was so controversial

aeyes 6y ago

Depends on the type of application, 99.9% of Wikimedia users are using the site without being logged in. If the site doesn't work without being logged in you could frustrate users and they might just use a different product instead of searching for their login after being logged in for a year or longer.

kazinator 6y ago

That doesn't seem difficult; just don't change the format of the session tokens. Eg a web application: you can substantially rewrite a web application, without invalidating logged in sessions. The point here is that the logged in sessions were suspected of being unauthorized. The unauthorized sessions had to be turfed, and the clearest way of being sure that all unauthorized sessions are turfed is to delete all the sessions. Of course, some those with unauthorized access will also try to log in to resume that unauthorized access, but presumably there is some trap laid for that. Maybe for the accounts suspected of having been breached, there will be a mandatory password recovery procedure or whatever. Or they will monitor for suspicious logins from different IP addresses.

pvg 6y ago
You can have state sitting in (serverside) session storage that is incompatible with the new version but you don't want users to lose. So now you have to migrate it, which can end up being actual work depending on the change.