This change surfaces most errors from the provider package as "user" errors that get a proper response generated for them instead of a 500 error.
In particular, @DrDaveD will be happy to know that I've had a change of heart on #14, for two reasons:
I looked at the code for the JWT auth plugin and it's at least as verbose, if not more verbose, than the changes I'm proposing here. So there's some precedent to this.
It turns out that when you return an err in your plugin it just gets written back as a 500 with the complete error text, so all of these errors that were user-facing but not marked as such (i.e., those that I didn't want propagated) were doing exactly that. I quote myself here: "a lot of consumers of these types of APIs just propagate error messages back upstream." Turns out those consumers is me.
By the way, the problem with returning 500s is that the Vault API client (the Go one, at least) just blindly retries those requests and masks the error that was originally returned, making debugging effectively impossible, as we learned this week.
Here's what an error response looks like now:
Error writing data to oauth/auth0/creds/test: Error making API request.
URL: PUT http://localhost:8200/v1/oauth/auth0/creds/test
Code: 400. Errors:
* exchange failed: oauth2: cannot fetch token: 403 Forbidden
Response: {"error":"invalid_grant","error_description":"Invalid authorization code"}
I was aware that the go oauth2 library blindly retries errors when retrieving a token. It does this when it doesn't know the authentication style. It's very annoying. It can be avoided by telling it the authstyle.
Dependencies:
This change surfaces most errors from the provider package as "user" errors that get a proper response generated for them instead of a 500 error.
In particular, @DrDaveD will be happy to know that I've had a change of heart on #14, for two reasons:
err
in your plugin it just gets written back as a 500 with the complete error text, so all of these errors that were user-facing but not marked as such (i.e., those that I didn't want propagated) were doing exactly that. I quote myself here: "a lot of consumers of these types of APIs just propagate error messages back upstream." Turns out those consumers is me.By the way, the problem with returning 500s is that the Vault API client (the Go one, at least) just blindly retries those requests and masks the error that was originally returned, making debugging effectively impossible, as we learned this week.
Here's what an error response looks like now: