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

Better way to differentiate between 400 errors. #198

Open
markhildreth-gravity opened this issue Dec 23, 2022 · 1 comment
Open

Better way to differentiate between 400 errors. #198

markhildreth-gravity opened this issue Dec 23, 2022 · 1 comment
Assignees

Comments

@markhildreth-gravity
Copy link

markhildreth-gravity commented Dec 23, 2022

When using GetProfileAndToken, there are a few cases where we might have an error. Namely:

  • The Client ID was invalid.
  • The Secret key was invalid or expired.
  • The code itself was invalid.

We want to handle these cases differently (e.g., have our callback handler return a 500 in the first two cases so alarm bells go off, but a 400 in the latter case since not our problem). However, it's difficult to do this because of the way that the error is returned in the SDK. The JSON bodies of these responses looks like this:

{"error":"invalid_client","error_description":"Invalid client_id."}
{"error":"invalid_client","error_description":"Invalid client secret."}
{"error":"invalid_grant","error_description":"The code 'XXXYYYZZZ' has expired or is invalid."}

...but the workos_error.HTTPError only returns the following:

Code: 400
Status: 400 Bad Request
RequestID: A UUID
ErrorCode: ""
Errors: []
FieldErrors: []
IsRequestError: true
Message (see below)

The message ends up using this logic to mash up the strings, so the three errors I talked about above would result in these Message values:

"invalid_client Invalid client_id"
"invalid_client Invalid client secret."
"invalid_grant The code 'XXXYYYZZZ' has expired or is invalid."

So in the end, while in theory the SDK gives us an error code so that a developer doesn't need to parse a string, I still end up needing to parse a string.

Ideally, the code (e.g., "invalid_client" and "invalid_grant") would be in a field like "ErrorCode.

@markhildreth-gravity markhildreth-gravity changed the title Better allow to differentiate between 400 errors. Better way to differentiate between 400 errors. Dec 23, 2022
@mthadley mthadley self-assigned this Apr 12, 2023
@emaincourt
Copy link

That is still very relevant as it also applies to handling all the authentication errors which is basically impossible in the current state of the SDK if I'm correct. Why was #203 closed ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants
@mthadley @emaincourt @markhildreth-gravity and others