fix(dbAuth): Fix WebAuthn when authModelAccessor is set to a custom value #11605
Conversation
|
@Josh-Walker-GM Please, let me know if anything needs to be changed, I would be happy to help release it as soon as possible. Don't really want to push on this, but this is holding us a little bit back, because we are migrating an existing app to Redwood and User table is already taken for other data. |
antonmoiseev
changed the title
antonmoiseev
changed the title
| where: { [webAuthnOptions.credentialFields.id]: credentialId }, | ||
| }) | ||
| .user() | ||
| const credential = await this.dbCredentialAccessor.findUnique({ |
There was a problem hiding this comment.
Switching to findUnique over findFirst could potentially be breaking for someone that didn't have a unique, or some other equivalent, index on the database column.
I'm happy to make this change in a minor/patch. Not having a unique constraint on your webauthn id field feels like an underlying issue in the users code. Our generator/setup tool adds an @id on the prisma model so would include an index as needed here.
|
Thanks @antonmoiseev! I'll get this out in the 8.3.0 release which I expect to go out in the next 24 hours or so |
…alue (#11605) - Instead of directly accessing auth model with hardcoded `user()` name, use `authModelAccessor` from DbAuthHandler options. - Also replaces `findFirst()` with `findUnique()` - we are querying data by the primary key. Feels semantically more correct, though may have no practical difference, I would expect Postgres to optimize query anyway if the only provided "where" criteria is PK.
user()name, useauthModelAccessorfrom DbAuthHandler options.findFirst()withfindUnique()- we are querying data by the primary key. Feels semantically more correct, though may have no practical difference, I would expect Postgres to optimize query anyway if the only provided "where" criteria is PK.