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)
Yes, something odd is going on, it is going to take me a bit of time to diagnose as I needed to patch up our logging here:
Seen it happen a few times on meta as well to random users
Thanks for the quick response @sam.
I just opened the Discourse native app (on iPhone 7) and found that I was logged out of my own forum.
This is the first time I’ve seen the problem first-hand.
Haven’t seen the problem in Safari yet though (my session was logged in this morning)
I upgraded my forum last night so it’s on very current code.
How’s the debugging going, @sam?
Update: just returned to the Discourse mobile app and got an error trying to access an admin page:
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)
When did you last update the forum ?
I did add some patches yesterday
Last night. It’s on v1.8.0.beta5+12
Oddly it told me the latest version is beta6 but when I checked the upgrade page:
OK, let’s try this one out!
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.
Excellent - thanks so much for the turnaround on this.
@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)
Thanks for the heads up, I am watching this very closely, will update once I have more fixes.
If I can provide any info or access to my forum to aid in debugging, please let me know.
Is this issue persisting for you on latest, I did do a round of this morning and could not find any new edge cases.
Note that after the fix is installed some accounts may still be delay logged off, but this should not repeat.
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.
I patched this up today:
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
Any updates, are you noticing that the issue is now gone?
One more very subtle fix today:
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)
Thanks @Sam - I’ll let you know if I see a recurrence.
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.
OK, up to you – I don’t have a strong opinion on it other than simplifying the code.