local installation, keys are expiring every few days

[pssara]

Hi, I am experiencing the following behaviour on my local installation. The user keys are expiring every few days. So, when the user connects, new keys are generated and have to be shared again. Can you add a configuration on the validity of the keys?

[MihanEntalpo]

Hello. I had plans on putting some environment variables into env.js file using simple bash template. I'll think about making this possible.

Till that time, you can change expire values here: https://github.com/MihanEntalpo/cryptboard.io/blob/2c5b8741557e8cd344a4fb9b7219225e9cda3790/web-app/public/js/frontend.js#L17 It regulates how long keys are stored in local storage of your browser Also, for user to not loss their uid, expire time on redis should be increased, I'll check the code, and send link to the needed line.

[pssara]

Dear @MihanEntalpo, thank you for your prompt reply and the great tools you share with the community. I see the code and read the expected behaviour to be 31 days. That is different from the experience I have. For me, the keys are regenerated every 1 or 2 days. Maybe it is a local configuration error on my computer. I will reverify.

[MihanEntalpo]

Acually, web-client not only need to store RSA keys, but it also need to be authorized in server. Authorization is made by calling /api/auth, when uid and session is generated, and access/refresh jwt tokens sent to client. session_id and uid is stored in Redis for 7 days: https://github.com/MihanEntalpo/cryptboard.io/blob/2c5b8741557e8cd344a4fb9b7219225e9cda3790/web-app/app/controller.php#L119

access_token has timeout set to 1 hour (by default): https://github.com/MihanEntalpo/cryptboard.io/blob/2c5b8741557e8cd344a4fb9b7219225e9cda3790/web-app/app/service.php#L12

refresh_token, used to request new access_token has timeout set to 24 hous: https://github.com/MihanEntalpo/cryptboard.io/blob/2c5b8741557e8cd344a4fb9b7219225e9cda3790/web-app/app/service.php#L23

If application is opened constantly, it check access token and refreshing it (if needed) every 30 seconds. On refresh new access and refresh tokens are generated, so, there are no problems with expiration.

But if jwt tokens did expire, client cannot continue to use his uid, because authorization is lost. So, even if keys are still saved in browser, uid would be refreshed, and user became new from the server's point of view. And from the point of view of any other clients, who has old uid in contact list.

So, you can increase access_token and refresh_token expiration time (by using ENV variables) and uid/session expiration time (expiration in Redis), and I'll get much more stable sessions for your local installation.

[MihanEntalpo]

Also, forget to mention. uid and session are also got refreshed in redis after /api/refresh is succesfully called. So everything is based on constantly running client. The idea behind this was: If user didn't clear their session, server should delete it automatically soon.

[MihanEntalpo]

If you have keys regenerated and you are sure that it's not uid regeneration - let me know, it would be a bug. You can click on your avatar, and get public key under the big picture in floating window (and the uid). You can store this somewhere and check after some days passed, what have changed actually

[pssara]

Thanks again. I am almost sure that it is the expiration in Redis. I need to figure out how to change this.

[MihanEntalpo]

@pssara did you managed to solve your problem?

[pssara]

Hi Mihan. Not really; after a few days, the uuid is always changed, even if the browser is always connected.