Unable to access `pending_authentication_token` in error response

[joshpensky]

Hi there!

We are testing out not-so-happy paths in our authentication flow, and found an issue with the password auth flow: https://workos.com/docs/reference/user-management/authentication/password

When the user's email is not verified, we expect to receive a email_verification_required error. However, the handle_error_response method in the WorkOS client doesn't pass along the code or pending_authentication_token fields to the default APIError class:

https://github.com/workos/workos-ruby/blob/68133ff28a86541effa65bd464d95efacd2320f6/lib/workos/client.rb#L169-L173

Could y'all make it so the else case here passes along the code and original error response if available?

Our workaround for now is to drop down to using the REST API via Faraday

[PaulAsjes]

Hi there, thanks for the report. We're looking into this and will report back soon.

[PaulAsjes]

This should now be fixed in v5.0.0!

[vddgil]

Hello there,

It's not fixed. When you use the method authenticate_with_password and you get an error code email_verification_required, a WorkOS::APIError exception is raised and this exception doesn't contain the needed data to continue the flow (pending_authentication_token and email_verification_id)

@PaulAsjes Maybe you could re-open this issue?

[sungwon]

Hi, I am having the same issue. It is not yet fixed. Could you please re-open?

Also, noting that the error response code 403 indicates that the API key used did not have the correct permissions, which is confusing. Most likely it should be a 400.

[sungwon]

I'm currently using a fork of the SDK and added a one-line hack to handle the 403 like a 400 in case this may help others move forward with their integration: https://github.com/sungwon/workos-ruby/blob/e718dcc539f1a0e11977774cd39fdaf7a07e5f3c/lib/workos/client.rb#L95

[PaulAsjes]

Sorry for the delay here, re-opening so we can fix this.

[semanticart]

@PaulAsjes any update on when this will be fixed? I'd hate to start off my company's WorkOS usage on a fork of the official gem.

[semanticart]

Not to armchair-quarterback, but it seems like there's a few clear options for moving forward here:

• Changing the status code for this scenario as @sungwon indicated. This feels most correct as an outside observer but could have unknown (to me) downstream effects
• Treat the 403 status the same as a 400 status (as seen in @sungwon's code)
• Add data to the APIError else-case. This is perhaps not as clean as getting a proper InvalidRequestError but the json = JSON.parse(response.body) has already happened so including data: json in the APIError at least solves the current problem of the pending_authentication_token being wholly inaccessible.

[PaulAsjes]

Sorry for the delay folks, I've added a new error type in the above PR that should handle 403 responses.