-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add support for non-revocable sessions #1392
Comments
non revocable session have been deprecated as they are quite insecure, I'm not sure we want to get those back |
I wouldn't say insecure, just less secure in that once a token is known the account can be accessed indefinitely. This was good enough for Parse until March 2015 and I could not find an announcement about deprecation, just that they are no longer the default. Revocable sessions were not fully supported in Unity clients until recently because Unity had a bug with HTTP errors not being handled correctly. This meant that a invalid session error would look like any other HTTP error so the client could have no special logout handling without applying it to all errors. This also meant that enabling revocable sessions with a Unity client was a risk in case Parse had an issue retrieving from _Session. Short term, the goal for me is for my app to work with parse-server exactly the same as it works on Parse.com, and I imagine this is shared by a lot of Parse customers. In my test, using a non-revocable session token on a Cloud Code call resulted in I also tested using a parse-server issued non-revocable token with a Parse.com hosted app (using the same database) and this worked fine. This means that users will at least not have to log back in if the server needs to be switched back due to a critical bug. |
+1 for this since we need this to implement social login which needs to fetch user's session for |
Non-revocable sessions were deprecated with the launch of revocable sessions on March 25 last year. Apps created after March 25, 2015 can only use revocable sessions. This issue only affects apps that have not migrated to the new, more secure session model. Instead of working around it by implementing the older session model in Parse Server, we suggest following our migration guide and migrating your user sessions to the newer revocable model. |
@hramos Can we login a user without knowing a password? |
@ralphilius you Can definitely write your own custom login logic through the Oauth adapters. You need 1 method to validated the authData passed through the Oauth login, and pass the ID of your 3rd party Auth. It don't have to be Oauth explicitly. We also have oauth for Google provided by parse server. Right away. |
@flovilmart I have seen the google oauth, but I don't get it how these adapters are called by clients and how they return required data (session/username & password) to clients log in. Sorry to ask but I don't get the big picture of this implementation yet. Thanks for support. |
You have to gather the auth token and user ID on the client. Then send those through the link method. The server will validate the auth token through the Google API, and on subsequent login, match the Google user ID you provided with the one initially provided upon linking or login. |
OK. For Java, I should call Please see this example:
I have only one doubt about the |
It should be what corresponds to the user_id returned by the API Call. Most likely the Google account ID |
@hramos I cannot find any announcement that non-revocable sessions are deprecated. The blog post talks about revocable sessions being "Enhanced Sessions", i.e. a recommended improvement rather than a replacement. While new apps do default to revocable sessions, it is possible to switch back on the General Settings page. Nothing will change for new apps if we add non-revocable session support and I agree that revocable sessions are a good idea and should be the default. I simply wish to add support for the existing Parse.com session handling. |
@steven-supersolid I needed this support and added a PR here: #1749 |
I have the same issue, I have an app that does non-revocable sessions, and per Ramos I went to the guide in - https://parse.com/tutorials/session-migration-tutorial. |
What version of parse-server are you running? |
I am using 2.2.18, and today I do not call [PFUser enableRevocableSessionInBackground] in my App. function handleParseError(err) {
} |
You should update to that version
Yes you need to add that line in the app delegate up upgrade the session token, then it all should update correctly. The session token in the response should start with an Then it's a good idea to handle invalid session tokens and prompt for a login as well. |
Thanks. Should I add [PFUser enableRevocableSessionInBackground] inside the block bellow as part of didFinishLaunchingWithOptions , as following -
Also, do I still need to ask the user to logout? If I will not add the support for handling invalid session token, will it work with 2.2.19. |
nope, the configuration block is not an async block. Do it that way:
calling |
It works, thank you allot for the quick help. |
Glad to know it works correctly, it wasn't tested on iOS, only with the JS SDK! Awesome! |
Closing as revocableSessionUpgrade has been implemented by #2646. |
I tested it with app written in Objective-C and I use Parse Client SDK 1.14.2 if somebody care to know. And the nice thing I did not had to add the recovery for the invalid Token, saved me a ton of time. Nice! |
Awesome! |
Hi @flovilmart, My parse server is hosted on AWS on Elastic Beanstalk, and per our previous exchange I start calling from the new version of the iOS app [PFUser enableRevocableSessionInBackground]. Message: Environment health has transitioned from Ok to Warning. 100.0 % of the requests are failing with HTTP 5xx. I download the logs from AWS, and found that I am getting the HTTP 500 error as a result of calling I am using Parse server 2.2.19, and Parse client SDK 1.14.2. I looked at commit 2646 that introduce enableRevocableSessionInBackground on Parse server and in SessionsRouter.js in handleUpdateToRevocableSession you access user.id when you build the sessionData. Maybe if the client app have an a anonymous user login to the app then the user.id is not defined ? In the nodes.log it complains about not defined _id. Is it possible that the AWS NGINX load balancer see the error 500 because of this and it report it to the health monitor in AWS which then report me the 500 error and move the server to degraded mode? Any suggestion how to fix this issue? Bellow are the logs for the times when I am getting the 500 error- /var/log/nginx/access.log172.31.57.70 - - [17/Sep/2016:13:30:54 +0000] "PUT /server/classes/_Installation/cVDvKNxn7j HTTP/1.1" 200 71 "-" "MyAppName/510 CFNetwork/758.5.3 Darwin/15.6.0" "107.77.223.68" /var/log/nodejs/nodejs.log�[31merror�[39m: Error handling request: [TypeError: Cannot read property 'id' of undefined] |
@mmarshak can you open an issue for that please? |
The anonymous users should have a user.id set as well. Also, ca you run with VERBOSE=1 so we have the full trace of the request/response for this error? |
I opened a new issue for this #2720. |
Hi @flovilmart I want to enable google login. |
You need to use that method, with google as auth type and a map with the access token set as authData. Please refer to the documentation on the wiki, the authentication modules are pretty straightforward |
@flovilmart https://github.com/ParsePlatform/parse-server/wiki/OAuth Also I don't see any |
If any laggards still need that parse session migration tutorial, look here: https://web.archive.org/web/20170101001730/https://parse.com/tutorials/session-migration-tutorial |
parse-server currently only supports revocable sessions but my live app uses legacy sessions. While there is some documentation about migrating sessions for a parse.com app, it is not clear what will happen when switching to parse-server. I would like to minimise changes when migrating my live app to parse-server.
I will do some tests on this and maybe submit a PR but have not examined the code in any detail yet. Legacy sessions could give a potential performance increase as the _Session collection would not be used in any requests.
The text was updated successfully, but these errors were encountered: