-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Invalid legacy session token after ParseUser.enableRevocableSessionInBackground #2845
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We've been unable to repro this on iOS |
Actually, we are seeing this on iOS too: http://crashes.to/s/743707c1b9c
|
Can you provide the server logs associate with that issue (when running with VERBOSE=1) and the steps to reproduce? |
Server logs - yeah I can probably do that. Steps to repro - I did provide some, are they not acceptable? |
I'll know more with the server logs. |
This issue has now affected at least 1,151 of our users on iOS http://crashes.to/s/95c28529e47 and 1,245 users on Android http://crashes.to/s/f1ea38ce61c. Logs:
As you can see there is basically no info in the heroku logs for |
I see that in your second logs, the server response is 400 (http://pastebin.com/raw/Z8AdaWkq). I don't believe this is the right server being hit as it doesn't even seem to pass the heroku router. There's not log involving parse-server failing to upgrade your token or else. |
Its the same server. I'm watching it live with |
ok, so I see in the cradle logs: See the test suite: https://github.com/ParsePlatform/parse-server/blob/ad707457be13f177e4a0dc481c990ddbd2df8d80/spec/RevocableSessionsUpgrade.spec.js#L72 |
Yes, thats the issue we're facing, see the issue desc above. Yes, that works around the issue. Please help fix the issue.
|
It should not accept the requests, as you're passing an explicitly bad session token... This is to match the behaviour with parse.com. We should never let a bad session token make request.
That's not a workaround, that's the expected behaviour... |
I'd appreciate some context with your comments. We're using the Android and iOS SDK, they are passing the token, not us. What did we do wrong? I don't think we did anything wrong. But if you do, please just specify what it is. |
Also, please respond to my point about
|
Please elaborate. We migrated from This has left thousands of our users screwed. What did we do wrong that causes our user's second devices to get this error? |
This is an open source project, improvements and PR are welcome.
You're not handling the error message that comes back from the server when you want to upgrade a session token that doesn't exist in the database. The legacy session token could be removed from your users for many reasons like an upgrade from another device etc... |
AND BTW, parse.com encouraged upgrading all your sessions to revocable sessions since march 2015 for security reasons. Legacy session tokens are shared across all devices where the user is logged in, revocable session tokens are unique per session (one per login). All get destroyed upon password reset etc... |
Again, i'd really appreciate some context. I get that tokens can become invalid, and I get how to handle them. Why are the tokens from our users's second devices invalid, but the first are fine? |
Is this helpful? We're in this situation now. Thanks for the lecture. |
@alexblack i'm taking on my own time to try to answer you, so please, if you'd show more patience that would probably help. Also, like I said, when you see the error that you have on the client, you should ask the user to login again, that will generate a proper session for the new device. |
I appreciate you taking the time to respond. Forgive me if I'm frustrated, I have thousands of users who's apps are not working due to their 2nd device getting the 209 invalid session token error on migrate. Yes I am aware we should prompt users to re-login. We have now implemented that, but these are apps, and and updates take time to roll out, and many users do not (or have not yet) updated. For users with legacy tokens, what was the proper migration path then? Our path was:
This works for our user's first devices, but not their other devices. Is this path not supported? |
it doesn't work for the secondary device because the legacy session token gets deleted when generating the new session token. This is a security measure to make sure the legacy session tokens are not used anymore when a new session is created, and similar with how parse.com handled the update. See the code here: https://github.com/ParsePlatform/parse-server/blob/master/src/Routers/SessionsRouter.js#L78 |
Damn. So it sounds like we should have stayed on parse.com, called |
The upgradeSession endpoint wasn't implemented until recently and we didn't verify the session token against legacy session tokens, so on parse-server all of your call were being unauthenticated. that would have been an option, another option would have been to migrate the session to revocable ones last year when it became 'deprecated'. |
@flovilmart I have hit the same wall and raised issue #3003 for same but not get any response yet. |
|
Issue Description
Our Android users with multiple devices are permanently getting
code=209, message=invalid legacy session token
on all but one of their devices.ParseUser.enableRevocableSessionInBackground()
What we see is:
a. The first device to update works fine
b. The other devices do not
So despite the other devices calling
ParseUser.enableRevocableSessionInBackground()
, they are still gettingcode=209, message=invalid legacy session token
on all parse operations.The only work around we've found is to get them to uninstall and reinstall the app on those devices.
Steps to reproduce
parse.com
parse-server
, and callsParseUser.enableRevocableSessionInBackground()
com.parse.ParseRequest$ParseRequestException: invalid session token
when the app starts up, when it tries to callParseUser.getCurrentUser().saveInBackground()
Expected result: apps on both devices work properly, and can do basic parse operations involving the
ParseUser
like saving it, saving other objects pointing to it etcEnvironment Setup
Code
Before (parse.com): https://gist.github.com/alexblack/a2c8bdde59608e85f192448f8e4dde84
After (parse-server): https://gist.github.com/alexblack/8fd376d54c1535a5b8777cbbef4b82df
Logs/Trace
Exception: http://crashes.to/s/16792fdcd3d
The text was updated successfully, but these errors were encountered: