On the SE23 Forum I’ve had a few bug reports today which concerned me.
The most notable error is a user being logged out twice when returning to the site on her iPad. “I came back to the site after some time and it auto-refreshed on my iPad. So I would see things as if I was logged in and then when it auto-refreshed, I was logged out. Hasn’t happened every time today, but happened twice”
I upgraded Discourse to the latest core code late last night, and also added the Data Explorer and Topic List Previews plugin.
In recent core updates I’ve noticed some commits regarding auth tokens. Is it possible a newly-introduced bug has caused my users to be logged out?
Other reports came in from a user who saw errors whilst seemingly logged in and trying to edit their own posts (possibly related to the same issue with expired login sessions)
Then as I clicked around further I realised I’d been logged out. So that’s two issues within the space of about an hour. Just wanted to mention in case this helped with the debugging. My forum is currently up-to-date vs the tests-passed branch)
Will leave this topic open till I have 100% confirmed it is fixed. I can pick up when this happens on meta cause I have some really robust logging going on.
@Sam - sorry to report I just got the same logout gremlin - on both the iPhone native app and Safari seemingly at the same time (this is with your fix taken in about two hours ago)
I’ve not seen a recurrence since my last post here. I’ll keep a close eye on things and let you know straight away if we see multiple recurrences for a given user.
This was a subtle issue where people using the app could end up being “double logged on” having both a cookie for auth and a user auth token. Combined that caused a bit of havoc.
I amended the logic so only one form of auth is respected, if you present both a cookie and user api key, we will only respect the user api key
There was a case in iOS where it would send old cookies cause a request got interrupted when app was kicked to background and then resumed when app got focus (with old cookie). Old behavior was to log off when it happened. New behavior is to give a bit more grace.
I do wonder though if I should simply always accept the previous token unconditionally. Cause it would simplify this weird turn of events. (at the moment prev token is only accepted for 1 minutes after new token is validated)
I don’t see any downside to always accepting previous token, this just effectively doubles the window of attack but if the window is ~10 minutes and the new window is ~20 minutes that does not seem like a big deal.
Also the paranoid can surely turn it down to ~5 minutes via the site setting of how long token grace period is, yes?
Sort of, it increases the window of attack quite a lot under certain conditions:
Jan 1 Token A is issued
Feb 1 Token A is rotated and B is issued and confirmed (user leaves site in less than 10 mins)
Feb 10 User returns
Under a laxer scheme we still accept Token A
Under current scheme we do not accept Token A cause Token B was issued and confirmed.
So, it is marginally less secure.
I am open to relaxing the rules here, but it does seem my previous fix is required for cases where “requests are trapped in a Safari webkit time travelling queue”, cause it is totally conceivable they could send us a token that was rotated many times since when you return to the tab and it replay requests.
