W
Wasp3mo ago
hadanator

Modify server authentication logic

In the server code for logging a user in, this logic exists:
export function getLoginRoute() {
return async function login(
req: Request<{ email: string; password: string; }>,
res: Response,
): Promise<Response<{ sessionId: string } | undefined>> {
const fields = req.body ?? {}
ensureValidArgs(fields)

const providerId = createProviderId("email", fields.email)
const authIdentity = await findAuthIdentity(providerId)
if (!authIdentity) {
throw createInvalidCredentialsError()
}
const providerData = getProviderDataWithPassword<'email'>(authIdentity.providerData)
if (!providerData.isEmailVerified) {
throw createInvalidCredentialsError() // CAN THIS BE CHANGED
}
try {
await verifyPassword(providerData.hashedPassword, fields.password);
} catch(e) {
throw createInvalidCredentialsError()
}
export function getLoginRoute() {
return async function login(
req: Request<{ email: string; password: string; }>,
res: Response,
): Promise<Response<{ sessionId: string } | undefined>> {
const fields = req.body ?? {}
ensureValidArgs(fields)

const providerId = createProviderId("email", fields.email)
const authIdentity = await findAuthIdentity(providerId)
if (!authIdentity) {
throw createInvalidCredentialsError()
}
const providerData = getProviderDataWithPassword<'email'>(authIdentity.providerData)
if (!providerData.isEmailVerified) {
throw createInvalidCredentialsError() // CAN THIS BE CHANGED
}
try {
await verifyPassword(providerData.hashedPassword, fields.password);
} catch(e) {
throw createInvalidCredentialsError()
}
Is there a way to handle the isEmailVerified check differently? Currently, if the user tries to login, and their email isn't verified yet, it just returns a 401 'invalid credentials' error. I want to try and return something about how their email isn't verified yet. Can I change this in my code, or would this need to be changed in the wasp source code?
3 Replies
kapa.ai
kapa.ai3mo ago
Hi @hadanator. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the available knowledge sources, Wasp’s default email authentication logic does not currently provide a built-in way to customize the error message when a user tries to log in with an unverified email. The default behavior is to return a generic "invalid credentials" error (401) if the email is not verified, as you observed in the code. To change this behavior and return a more specific error (e.g., "email not verified"), you would need to implement a custom login action. The knowledge sources show that for signup, you can create a custom action to handle specific cases and return custom messages. The same approach can be applied to login: you would need to override the default login logic by creating your own login action in the src/auth directory, where you can check isEmailVerified and throw a custom error or return a custom response as needed. However, this is not something you can do by simply configuring Wasp; it requires you to write your own login logic. The default Wasp forms and actions do not expose a way to customize this error message without such an override. This is confirmed by community discussions and the documentation, which suggest that for more granular control over authentication flows and error handling, you need to implement custom actions and use Prisma directly if necessary. There is also an open issue about improving error messaging for login and signup, indicating this is a known limitation in the current Wasp implementation Custom auth error messages? (Discord), Improve the error messaging on Login & Signup (GitHub). Summary:
You cannot change this behavior via configuration; you need to implement a custom login action in your code to handle the isEmailVerified check differently and return a custom error message. This would not require changing the Wasp source code itself, just overriding the default login logic in your app. If you need an example of how to create a custom signup action (which you can adapt for login), see the documentation: Creating a Custom Sign-up Action. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @hadanator, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
Vinny (@Wasp)
Vinny (@Wasp)3mo ago
Hmm I don't think this is possible without creating your own custom signup flow @hadanator. Maybe @miho knows a workaround?
hadanator
hadanatorOP3mo ago
Yeah I asked in general about it, and either way changing what the response is was determined to be a security issue, so I've just left it as is.

Did you find this page helpful?