I need some guidance or clarification to solve a tough problem I’m currently facing.
I developed a reservation platform for my town’s tennis club, where each user SHOULD have an affiliation with the organization (and therefore a unique number).
This number is used as the username because even children who don’t have an email address can log in and book a court (or be invited by others).
The issue is that I have a few rare but existing cases where someone is affiliated with the club but not with the tennis federation (and then do not have a membership number). For these rare cases, I would like to offer the option to log in using an email address. Is it possible to set up the login to match either the federation membership number or the email address? I’ve gone through the documentation, but there’s nothing about this.
@rob Hey - any thoughts on this? It seems like a similar usecase to social logins + email. I’m not sure though. Where you can login with google/github/etc. or create a username directly in the system.
In dbAuth, internally, the field is called username and can contain any string at all—it’s just a unique field used to identify the person, along with their password. So there’s nothing stopping you from storing membership numbers and email addresses in that same column. As long as the text that was submitted in the form matches the text in the database, dbAuth is happy to let the user login.
Can you have that field be dual purpose and store both registration numbers and email addresses? You could provide some kind of flow after logging in with an email address to “upgrade” their account to use a membership number—just replace their email with the number instead and now they log in with that instead.
If for other data integrity reasons you can’t repurpose that column, what about creating a new one called something like login and that will be a duplicate of the data from the membership number column, but can now also contain email addresses. Tell dbAuth to use that column as the username column and you’re good to go!
Your second proposal is what I was beginning to consider; it could be a workaround that would solve the problem.
This proposal should probably be made through a Github issue, but what do you think about adding a predicate at the authentication configuration level to determine the username table?
Or even, exposing the username query code to allow fine-tuning this behavior for use cases like this one?
So there already is config for telling dbAuth what table and column name to use for username! There are lots of comments in /api/src/functions/auth.js describing what each one does, but take a look at authModelAccessor and authFields. Here you tell dbAuth what Prisma model to use for your user table and what columns you’re using for the required dbAuth property names:
// The name of the property you'd call on `db` to access your user table.
// i.e. if your Prisma model is named `User` this value would be `user`, as in `db.user`
authModelAccessor: 'user',
// A map of what dbAuth calls a field to what your database calls it.
// `id` is whatever column you use to uniquely identify a user (probably
// something like `id` or `userId` or even `email`)
authFields: {
id: 'id',
username: 'email',
hashedPassword: 'hashedPassword',
salt: 'salt',
resetToken: 'resetToken',
resetTokenExpiresAt: 'resetTokenExpiresAt',
}