Request for Improved Response Status in supabase.auth

[mashwishi]

I'd like to open a discussion regarding the current response structure in supabase.auth. Currently, when making requests related to user authentication, we receive JSON responses that look like this:

For invalid credentials:

{"data": {"session": null, "user": null}, "error": [AuthApiError: Invalid login credentials]}

For unconfirmed accounts:

{"data": {"session": null, "user": null}, "error": [AuthApiError: Email not confirmed]}

In scenarios where a user registers but hasn't yet confirmed their email, this "Email not confirmed" string is used in the response. However, this string is subject to change in future updates, making it less reliable for developers to build upon.

Proposal

I propose that Supabase consider implementing a more standardized status code approach in the response, in addition to or instead of the current error messages. For instance:

For invalid credentials, a status code of 401:

{"data": {"session": null, "user": null}, "error": [AuthApiError: Invalid login credentials], "status": 401}

For unconfirmed accounts, a status code of 435:

{"data": {"session": null, "user": null}, "error": [AuthApiError: Email not confirmed], "status": 435}

By using standardized status codes, developers can rely on consistent responses and don't have to rely on parsing error message strings, which can change over time.

Benefits

• Improved developer experience: Consistent status codes make it easier for front-end developers like myself to handle different authentication scenarios without relying on error message strings.

• Future-proofing: Status codes are less likely to change, providing a stable foundation for building on top of Supabase's authentication system.

• Clarity in documentation: If adding status codes directly to the response is not feasible, consider updating the documentation to clarify the meaning of specific error messages.

I believe this change would greatly benefit the Supabase community, especially front-end developers who rely on Supabase without a backend. Let's discuss this proposal and explore how we can enhance the developer experience.

Video Attachment

I have attached a video to this discussion post to visually demonstrate the scenario I mentioned, showcasing the potential benefits of this proposal.

Thank you for considering this suggestion, and I look forward to hearing from the community and the Supabase team regarding this matter. Your feedback and insights are greatly appreciated.

0924.mp4

[mashwishi]

Hope its error number not string

[hf]

This is planned and high-up on the priority list. Keeping the issue open until we have it.

[tom-at-pixel]

@hf Thanks for prioritizing this. Do you have a rough timeline for this work? This is a critical feature for localized apps. Right now, we have to identify the error type from the error message, then map that to our language-specific strings to show the user. Every now and then we have to check that the strings haven't changed, which doesn't feel right. Thank you and the team for looking at this! 😊

[hf]

@tom-at-pixel This is worked on and I'm leading it. Goal is to have something out in the next few weeks. Main PR is here if you want to follow along, though still early stages: supabase/auth#1377