Setting password via /setpassword signs in user. Does not generate re-authentication credentials.

If you haven’t already, check out our contributing guidelines for onboarding!

---

view the job on Upwork here.

Platform - version:
Current

Problem

It doesn’t seem like we are generating re-authentication credentials when a user hits https://expensify.cash/setpassword/[validateCode].

Why is this important?

I think anyone setting a password will be logged out when their authToken expires. And ideally they won’t be logged out at all once a password is set.

Solution

Generalize the logic here into a private action that can be used in the signIn() and setPassword() flows.

[marcaaron]

Plan sounds good. We can reproduce an authToken expiring by modifying the localStorage key session and deleting some characters from session.authToken - tapping on a new chat or trying to take any API action should in this case not log you out but refresh the token instead.

https://user-images.githubusercontent.com/32969087/108240312-d13e9900-70ee-11eb-8125-abd62723111d.mp4

[anthony-hull]

For this issue I would refactor the functionality into a new function in the Session.js action file and call that from within the signIn and setPassword functions, making it re-usable and keeping the code DRY. This is to all setPassword to set up the re-authentication credentials for when the token expires without reproducing the code from the signIn action.

I would first try to re-produce the “authToken expiration after re-setting” edge case. I would then call then confirm the desired refreshing of auth tokens take place after the change.

How long lived are the tokens? Do you have any advice on how to re-produce this edge case on demand? Otherwise I would look at a way to force this to happen to speed the feedback loop up if the token lives longer than a few minutes.