Repository navigation
Queries never fail with 'InvalidSessionToken' error when user is logged with legacy session token #1605
Description
Check out this issue for an ideal bug report. The closer your issue report is to that one, the more likely we are to be able to help, and the more likely we will be to fix the issue quickly!
For implementation related questions or technical support, please refer to the Stack Overflow and Server Fault communities.
Make sure these boxes are checked before submitting your issue -- thanks for reporting issues back to Parse Server!
- You've met the prerequisites.
- You're running the latest version of Parse Server.
- You've searched through existing issues. Chances are that your issue has been reported or resolved before.
Environment Setup
- Parse hosted app has only legacy user sessions
- Database migration has been done to MongoDB 3.0.10 running on a AWS instance
- Local Parse-Server on Node 5.10.1, that point to the migrated databse on AWS
- iOS client, using SDK 1.12.0, that has a user already logged with the legacy user sessions, and that point to a local Parse-Server
Steps to reproduce
- Launch the iOS client
- Make it trigger a ParseQuery that don't need any specific permission to succeed => The query returns with no error and the data are OK
- Make it trigger a ParseQuery that read data and need permission to succeed, like a fetch() on the current user => The query returns code 101
- Make it trigger a ParseQuery that modify data and need permission to succeed, like a save() on the current user => The query returns code 206
The problem is that the queries doesn't return the error 209 as explained in the Session Migration Tutorial here : https://parse.com/tutorials/session-migration-tutorial
So it's impossible to handle this case to inform my users that they must log out then log in.
Additional information :
When I add "[PFUser enableRevocableSessionInBackground]" to the iOS client, no Session object is created after launching the client.
Activity
[-]Queries never fail with 'InvalidSessionToken' error code when use is logged with the legacy session token[/-][+]Queries never fail with 'InvalidSessionToken' error when user is logged with legacy session token[/+]cjosepha commentedon Jun 1, 2016
Anyone has experienced this issue?
cyu commentedon Jun 1, 2016
I ran into this issue too - the last I check the parse server only returns 209 on any requests involving sessions.
I wound up working around this issue by calling
[PFSession getCurrentSessionInBackground]at startup. This call will return the 209 you're looking for.sirnacnud commentedon Jun 21, 2016
I also noticed that 209 is only returned when the request involves sessions. I can invalidate the user's session through the dashboard or other means, and the user can still make normal queries. From my understanding of the Parse documentation, after the session has been revoked, all requests should return 209.
sirnacnud commentedon Jun 21, 2016
Looks like this issue was already brought up and closed, but not resolved, see #779
cjosepha commentedon Jun 26, 2016
@cyu I followed your work around and this worked for me, but of course calling
[PFSession getCurrentSessionInBackground]at startup is not the ideal solution : if the user open an app that is already launched, we will no trigger this code.@sirnacnud Yes according to the documentation, all queries should return 209, but this is not the case at all : only way to get this error and then ask the user to log in again is to call
[PFSession getCurrentSessionInBackground]For information, the problem is exactly the same with the Android SDK.
cjosepha commentedon Jun 26, 2016
What I understand is that parse-server doesn't handle legacy sessions, and this is the cause of this issue. So the problem here is that we should have modified our Cloud Code to use revocable session before starting to migrate to parse-sever. See #1729 and #1749 for more details.
flovilmart commentedon Jun 26, 2016
We could implement the 209 fail upon failing session token in every requests I believe. What do you think @drew-gross ?