Can't override error type for client for servers that don't adhere to spec. about oauth2-rs

[ramosbugs]

Unfortunately, arbitrary error responses aren't supported by the library. The spec is pretty clear about the error response format: https://tools.ietf.org/html/rfc6749#section-5.2. The extensibility in the library allows for additional error codes (as mentioned in https://tools.ietf.org/html/rfc6749#section-11.4), but not an entirely different serialization format.

If you're not in a position to be able to change the server error response format, my recommendation is to manually parse the contents returned in RequestTokenError::Parse, which should let you read the error response in an arbitrary format. One enhancement to facilitate this would be to include the HTTP response code in RequestTokenError::Parse, but that would be a breaking change that would need to wait for a 3.x version bump.

[dnsco]

I can understand hesitancy to change things if it would require a 3.x bump, I thought things could still be changed because 2.0 hasn't actually been released yet.

It is a bummer that interfacing with a non-standards-compliant external provider is so complicated, but I'm powerless to change things on there side. There is an asymmetry in that the library arbitrary control over parsing of successful responses, but does not allow the same control for error handling.

I have implemented error handling in my app, but it's actually quite complicated, and was surprised that it was necessary for the error case, when it was not necessary for the success case, and I expected the two generic parameters to Client to work the same.

If things can be changed, and a pull request would be welcomed, I would more than happy to take a crack at it. It seems like ErrorResponse could be the trait, and the parameterization could be isolated to the BasicErrorResponse. I could also be misunderstanding how complicated of a change this would be.

It's also not the end of the world as a work around was possible, and I understand wanting to constrain scope.

Thanks again for the library!

[ramosbugs]

You raise an excellent point about the asymmetry between the successful response parsing and the error response parsing. #52 described a similar non-compliant situation, and I made TokenResponse a trait to support that use case. I agree it would make sense to do the same here, for consistency. Unfortunately, that would also be a breaking change, and the API was officially stabilized in https://github.com/ramosbugs/oauth2-rs/releases/tag/2.0.0-beta.1 since no new issues had come in for quite a while during the alpha period.

That said, I'm not opposed to creating a 2.x maintenance branch and bumping the version on master to 3.x in order to accept a PR to do this.

[dnsco]

Awesome! I'll take a crack at it!

[dnsco]

I just looked at the semantic versioning spec, and it says:

A pre-release version indicates that the version is unstable and might not satisfy
the intended compatibility requirements as denoted by its associated normal version.

My interpretation of that is that another major bump is not necessary.

[dnsco]

#60 merged :)