After v5 upgrade - dbAuth: Invalid Reset Token

AlexRoosWork · July 17, 2023, 12:38pm

Hey there,

just did the upgrade to v5 following the guide here on the community forum. Now it seems that the resetPassword functionality with dbAuth is broken for me.

What is the problem

I completed the upgrade guide.
Testing the resetPassword functionality, I do get the notification with a resetPassword link, the resetToken is included in the URL and stored on my user in the database.
However, when I enter the site with the resetToken in the URL, the toaster “Invalid Reset Token” gets immediately displayed.
This is weird, because it should find my user with that token… I can see it in prisma studio!
I find it also weird that the token is just something like this 1NXg-A - not a hash, as I would expect…

How can I troubleshoot this further? I can log the token on the frontend - it’s correct. But I cannot find the place in the code where the database query is done. So I am unsure what the issue is…

noire.munich · July 21, 2023, 9:41am

Hi @AlexRoosWork

Most likely, it’s not in your code but in the FW’s code that the issue is happening:

github.com

redwoodjs/redwood/blob/main/packages/auth-providers/dbAuth/api/src/DbAuthHandler.ts#L595


      
              throw new DbAuthError.NoUserIdError()
            }
          
          
  return this._loginResponse(handlerUser)
          }
          
          
logout() {
            return this._logoutResponse()
          }
          
          
async resetPassword() {
            const { enabled = true } = this.options.resetPassword
            if (!enabled) {
              throw new DbAuthError.FlowNotEnabledError(
                (this.options.resetPassword as ResetPasswordFlowOptions)?.errors
                  ?.flowNotEnabled || `Reset password flow is not enabled`
              )
            }
            const { password, resetToken } = this.params
          
          
  // is the resetToken present?

I have the same issue but cannot confirm when it appeared first.

noire.munich · July 21, 2023, 9:59am

Ok so it comes from here:

github.com/redwoodjs/redwood

feat: Change to using resetToken hash in DB

redwoodjs:main ← jaiakt:jai-reset-token-hash

opened 05:12AM - 12 Apr 23 UTC

jaiakt

+49 -17

Addresses https://github.com/redwoodjs/redwood/issues/6855. This PR makes it so… we don't store raw `resetToken`s in our database but instead, the sha256 hash of the token. This makes it so if a database is compromised, an attacker can't steal `resetToken`s and reset users' passwords. One catch with this PR is that the user defined `handler()` takes in a `User` object which it relies on for fetching the `resetToken` to generate a password reset link. Because now the `User` object will instead contain a `resetToken` hash, we need to make the raw token also available. I solve this by mutating the `User` object before calling the handler and explain this in the documentation for `forgotPassword.handler()`. This is potentially breaking if the application refetches the `User` object in the handler but not sure why they'd do that 🤔 Edit by Tobbe: I've marked this as feature-breaking, but it's not really breaking. Just wanted to make sure that we highlight that any in-transit password resets will break when users upgrade RW to whatever version this is released in. For low- to medium-traffic sites it's probably not a problem. Maybe just have an error message that asks users to try again if the token doesn't match. For high-traffic sites, and/or for the best end-user experience, what developers can do is temporarily disable pw resets. Query their db and wait until no more valid reset tokens exist (by looking at `resetTokenExpiresAt`) and then upgrade and finally re-enable pw resets

and here feat: Change to using resetToken hash in DB (#8041) · redwoodjs/redwood@08e092f · GitHub

Not sure yet what to do, but according to the discussions you should be able to simply reset a token after your upgrade and go with it .

noire.munich · July 21, 2023, 10:59am

Ok so apparently now the framework returns the raw version of the token only when using forgotPassword, but it gets removed if your own handler for this method is returning an object.

So to “solve” this, in my use case, I changed the forgotPassword handler to return only the resetToken, which is the raw version of it, not the hash one. I then use it for the email I send to welcome my users and whatever I need it for in the frontend.

This code has been problematic to me as it removes the resetToken if my forgotPassword handler returns a user, something I would not expect:

github.com

redwoodjs/redwood/blob/main/packages/auth-providers/dbAuth/api/src/DbAuthHandler.ts#L529C42-L529C42


      
          if (typeof response === 'object') {

Is this of any help @AlexRoosWork ?

AlexRoosWork · July 25, 2023, 8:10am

Thank you so much for the detailed help!

What lead to the issue for me was that I was generating my own resetTokens and storing them to the database myself in the forgotPasswordOptions.

I just removed the call to nanoId and let Redwood do it’s thing. Now everything works as expected: The user that arrives in the forgotPassword already has the resetToken, which gets stored as a hash in the DB and the resetting of passwords works!