Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export an Error type that can be caught and handled #719

Closed
Pipeliner opened this issue May 10, 2022 · 4 comments
Closed

Export an Error type that can be caught and handled #719

Pipeliner opened this issue May 10, 2022 · 4 comments
Labels
enhancement An enhancement or improvement to the SDK that could not be otherwise categorized as a new feature

Comments

@Pipeliner
Copy link

Describe the problem you'd like to have solved

On errors, Auth0 throws Error objects that can't be easily differentiated from other kind of errors.
e.g. PasswordlessAuthenticator.signIn() can throw a lot of different errors depending on problems with the token / user being blocked / etc.

I can't easily differentiate these errors from other errors that might happen in my code or other libraries.

Describe the ideal solution

There is a base class for Auth0 errors (and maybe subclasses for specific errors)

Alternatives and current work-arounds

I can try to catch SanitizedErrors which happen to be the errors which Auth0 usually throw. However, this is not documented anywhere and is there not guaranteed to be the case.

Additional information, if any

--

@nicholeuf
Copy link

Yes, +1 to this. I am also noticing that the error description is not simple to derive either. I am looking to extract the following to return in the response to several requests (password grant, database signup, request change password email, and update auth0 user):

  1. The status code
  2. A human-readable message

I have looked through the code of both this library and rest-facade in these locations:

Status Code ✅

The error.statusCode is consistently available for this value.

Message ❓

I am currently using the error.message field, a stringified json object. I am noticing the object has an inconsistent shape, depending on the error/action. Based on the examples I've seen, I am using the parsed error.message description or error_description as of right now. It would be great, if this were derived for clients in a more consistent, clear way.

What is the best way to extract a human-readable error message?

A few examples with inconsistencies:

Password grant with wrong password

I am seeing the following:

{
  error: 'invalid_grant',
  error_description: 'Wrong email or password.'
}

Database signup user exists

I am seeing the following:

{
  name: 'BadRequestError',
  code: 'user_exists',
  description: 'The user already exists.',
  statusCode: 400
}

@adamjmcgrath
Copy link
Contributor

Thanks for raising this @Pipeliner

I don't see a short term solution to this, but I'll leave this open as an enhancement for when we consider the next iteration of this SDK

@adamjmcgrath adamjmcgrath added the enhancement An enhancement or improvement to the SDK that could not be otherwise categorized as a new feature label May 19, 2022
@stale
Copy link

stale bot commented Oct 30, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you have not received a response for our team (apologies for the delay) and this is still a blocker, please reply with additional information or just a ping. Thank you for your contribution! 🙇‍♂️

@stale stale bot added the closed:stale Issue or PR has not seen activity recently label Oct 30, 2022
@Widcket Widcket removed the closed:stale Issue or PR has not seen activity recently label Oct 31, 2022
@adamjmcgrath
Copy link
Contributor

I'm pleased to report that the Beta of v4 is now available. This has been rewritten in TypeScript and has full type coverage of Auth0's Management and Authentication APIs (including error types)

Closing this thread in favour of #859

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or improvement to the SDK that could not be otherwise categorized as a new feature
Projects
None yet
Development

No branches or pull requests

4 participants