recoverAccount workflow

[ljosberinn]

Hi, so I've been tinkering with a reset-password route for a while and found this issue:

• request a password recovery via requestPasswordRecovery(mail) -> netlify sends out reset mail
• runRoutes triggers and... well, does nothing - which I guess is fine, just a heads up in the docs would've been nice
• so I circumvented this by catching the recovery token myself and rerouting it to my route
• there, recoverAccount(token) fetches a User object based on the verified token but performs no login, valid too
• while this happens, the user can enter his new password and then submit
• I'm now in possession of a regular User object, together with a valid JWT through the token and the new password - I should now be able to update the password via updateUser({ password }) - but because recoverAccount(token) didn't change any lib internal state, it throws the are you logged in error.
• so I manually feed the token-verification User obj to the lib because after the state change, user is no longer null
• it finally executes user!.update(fields).then(_setUser) in another effect where I have to ignore errors thrown from the lib - not sure why these are triggered

It's finally working but imo that's a mess. Am I doing something massively wrong here?

[swyxio]

i dont think so. im not sure why i commented out that line in runRoutes. i think there was a PR complaining about this a while back but i dont think i accepted it. (edit: ah - i think this is because it’s better implemented in react-netlify-identity-widget? thats what i use anyway)

in any case - please feel free to PR what you think should be done - you have clearly done all the necessary research to fully understand this problem. I’m not currently active on this project right now but could very well come back to it at any time

[ljosberinn]

Brainstorming here a little, let me know if this is over the top.

• have recoverAccount(token) trigger _setUser which performs a login (and also return the userObj to the dev, still)
  • it would then be the developers duty to redirect him to whatever route that allows him to change password based on...
• have runRoutes return an obj of shape

{
 token: string | undefined,
 type: 'confirmation' | 'invite' | 'recovery' | 'email_change' | 'access' | 'confirmation' | undefined
}

which sets it to a new internal state param which gets returned from the hook so developers can just use

const { replace } = useHistory();
const { param: { token, type }, user } = useIdentityContext();

if(token) {
  switch(type) {
    case 'recovery':
        replace('/settings/change-password');
        break;
    // etc
  }

  return null;
}

Also, recoverAccount(token) and all other functions using token would need to consume said token and remove it afterwards.

[swyxio]

this is an interesting approach! i was tempted to suggest returning an array of tokens, but realistically i dont think that is ever going to happen. so i think this works. if you'd like to try a PR, be my guest, if not i'll take a crack whenever i get back to this