You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
OAuth error, exactly like the react one, bonus points for enumerating some of the more common spec'ed codes
CredentialsManager error, perhaps containing an OAuth error as a cause (e.g. refresh token expiration from the server), or something else related to retrieval
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:
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
The text was updated successfully, but these errors were encountered: