Open thyming opened 2 months ago
We're facing the same problem. We wanted to anticipate which errors we might encounter from the authorize
call, but the error types are non-existent.
We also had to manually inspect the errors, but the only one we could consistently reproduce was user_cancelled
. Reproducing other types of errors, such as timeouts or issues when the authorization server is down seems very difficult and time-consuming.
Having a typed error object would definitely help us predict which errors to expect and how to respond to them. For now, we will log them and analyze the data over time.
I'm also encountering the a0.credential_manager.invalid
issue in my production application, with various error descriptions, including:
This issue is critical for us, as it affects the reliability of our authentication flow. I would appreciate further support in diagnosing and resolving this issue, as it's impacting our production environment.
For the native side, clear error codes are provided in the documentation: Android and iOS.
If a clear way to handle these errors is provided, it would be very helpful to us.
I also attempted to handle these errors using error messages but encountered the following issue:
Platform-Specific Error Message:
The SDK returns the same type of error but with two different error descriptions across platforms, making it challenging to handle these errors effectively without consistent error codes.
iOS-specific error message: No credentials were found in the store. As per the documentation, the reason for failure is not provided.
Android-specific error message: No Credentials were previously set.
Checklist
Describe the problem you'd like to have solved
I would like to be able to handle common and expected errors in the auth flow gracefully. For example, if the user closes the login popup, this throws an error, or if a refresh token is expired, this throws an error. However, the error codes and structures are undocumented, platform-specific, and untyped in typescript.
Describe the ideal solution
The error object returned by
useAuth0
should be a typed error object with enumerated error codes that are not platform-specific except when strictly necessary. The react SDK does something like this without having the typed error codes, but at least you can reference the oauth error codes from the spec.One can imagine at least two error classes that this library could implement:
Alternatives and current workarounds
The current workaround that we use in our codebase is that we have inspected errors that come out in these cases and reverse engineered the error API from that. Something like:
which feels quite brittle as an undocumented, platform-specific API.
Additional context
No response