Hi! With the current session strategy, if I use a mobile sdk, after the expiration time, the user must login again (there isn’t a token renew action like jwt); but this kind of ux is bad on a mobile situation. Is there a better alternative strategy?
1 Like
Current timeout for sessions is 1 year if I remember correctly. Do you want to increase that?
No, i know there is a config parameter to extend sessiontoken timeout, but i 'm asking if there is a sort of behaviour like jwt token to extend dynamically (from client) the expiration time.
Current session behaviour has two problems:
- security problem(it’s better to avoid long life tokens)
- bad user experience from a mobile perspective → the user should login again after the expiration date also if he uses the app frequently
As long as I know, there isn’t an endpoint to renew the tokens but it looks we should discussing adding this. @Manuel @dplewis thoughts?
I think this would be a useful addition to Parse Server and it is a commonly used mechanism.
Whether a developer wants this or not depends on the individual security policy, so any such renewal mechanism should be optionally configurable. In addition, these renewal mechanisms usually have a maximum renewal lifespan after which a user has to manually authenticate again, regardless of whether they have a still valid token, to prevent renewing tokens indefinitely. But also a maximum renewal lifespan is something a developer may want or not, so that would also have to be optional or theoretically indefinite, say 999 years.
1 Like
I think another option could be to link the renewal lifespan to the frequency of usage: e.g social network apps, like Facebook or Twitter, that are used every day, so if X days have passed since the last use, the token expires definitely and the user must login again.
I also find @pgulinelli an excellent idea to implement OAuth 2.0 to Parse Server.
I would really like to be able to help in this step, but I don’t feel confident in how to set up the development environment to implement this feature. But I can make it available as I did in PHP. @davimacedo, @dplewis and @Manuel, can I send it to you?
As a suggestion I will describe the points:
1 - Parse should provide the following URL Alias:
https://mydomain.com/.well-known/openid-configuration
This is responsible for listing public certificates
{
"issuer": "https://mydomain.com/",
"authorization_endpoint": "https://mydomain.comauth/authorization",
"token_endpoint": "https://mydomain.comauth/token",
"userinfo_endpoint": "https://mydomain.comauth/userinfo",
"revocation_endpoint": "https://mydomain.comauth/revoke",
"jwks_uri": "https://mydomain.com/auth/certs",
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"iat",
"iss",
"name",
"picture",
"sub"
],
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}
The url of public certificates for JWT validation (https://mydomain.com/certs)
{
"keys": [
{
"use": "sig",
"kid": "38931....4cec59",
"e": "AQAB",
"kty": "RSA",
"alg": "RS256",
"n": "1eUHLL....PbHBCw"
}
]
}
2 - The login method will be changed to return in addition to the Parse User data, the Access Token and the Refresh Token;
3 - The Access Token must expire for 24 hours, and a different value can be defined;
4 - The Refresh Token should only be used to generate a new Access Token if it has expired;
5 - The Logout method will revoke the Refresh Tokens, respectively, the Access Tokens section.
I really want to be able to contribute to the implementation of this function in the project.
Yes, that could be an additional aspect of parametrization, i.e. an additional parameter.
I think you can start opening an issue at the Parse Server repository for discussion and start working on a PR. You can see more details on our contributing guide: parse-server/CONTRIBUTING.md at master · parse-community/parse-server · GitHub
I followed the steps to start development, but how do I run “parse-server-example” and start calls?
$ git clone https://github.com/parse-community/parse-server
$ cd parse-server # go into the clone directory
$ npm install # install all the node dependencies
$ code . # launch vscode
$ npm run watch # run babel watching for local file changes@davimacedo , I already managed, but I have to restart each change 
is it possible to keep “watch” the parse-server-example?
I managed to change the call in index.js (parse-server-example)
const ParseServer = require('C:/src/parse-server').ParseServer;You don’t need to use parse-server-example in order to start parse server for development purposes. You can use built-in cli. Something like this would start it:
./bin/parse-server --appId APPLICATION_ID --masterKey MASTER_KEY --databaseURI mongodb://localhost/test
In terms of watch, you can use a module like GitHub - kimmobrunfeldt/chokidar-cli: Fast cross-platform cli utility to watch file system changes
@davimacedo I did the PR of what we talked about here, but it is giving 2 errors with the codecov. I don’t know how to fix this, can you help me? On my local machine, all tests worked correctly.
You are missing test cases. Test cases proves that this feature works. I listed a few in my comment