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

How to handle cancelled login or access denied #75

Open
ProNotion opened this issue Jun 24, 2015 · 11 comments
Open

How to handle cancelled login or access denied #75

ProNotion opened this issue Jun 24, 2015 · 11 comments

Comments

@ProNotion
Copy link
Contributor

How are people handling the scenario where someone chooses a login service, gets redirected to the service login page and then decides to cancel the process. Currently an exception of type 'OAuth2.Client.UnexpectedResponseException' is thrown but that doesn't really handle the situation.

Thanks

@ProNotion
Copy link
Contributor Author

I've started work on some better handling of errors based on RFC 6749 and extended the UnexpectedResponseException to feed this information back if it exists. I will submit a pull request for this once I think I have it working as I think it should. I have a live site with a custom IClient (Yahoo) that I need this for now so that should be a good test.

@niemyjski
Copy link
Collaborator

hmm, what would this fall under for error type? I'm thinking that maybe we should have an exception type for each one of those scenaros?

@ProNotion
Copy link
Contributor Author

Sure, I can implement it that way if you'd like. Currently I have extended the UnexpectedResponseException class to have ErrorCode and ErrorDescription proeprties with an overloaded constructor like public UnexpectedResponseException(string fieldName, string errorCode, string errorDescription) but that's still pretty generic.

@niemyjski
Copy link
Collaborator

What do you think? Seems like we use UnexpectedResponseException for a lot of things

@ProNotion
Copy link
Contributor Author

I'm inclined to agree with you as it makes for easier handling of each scenario and allows us to populate the exceptions with the relevant information from each of the responses without the ambiguity.

@niemyjski
Copy link
Collaborator

I think we should do it :) @titarenko what do you think?

@titarenko
Copy link
Owner

Essentially, when I added class UnexpectedResponseException I was thinking about really unexpected response, like something really unknown and unexpected. I think we can add something more specific for handling of "expected" cases, when we know that this thing can happen.

P. S. Sorry for very late responses, I'm very busy with my primary projects and rarely have spare time now.

@niemyjski
Copy link
Collaborator

@titarenko Thanks for your response, we are all in that boat :). I'm just trying to help where I can :). (P.S., I need access to the build server :)).

@marpstar
Copy link

We too had this issue, where when the user clicks cancel while giving their credentials to the third party provider. I've taken a similar approach to the one @ProNotion has outlined, reusing the UnexpectedResponseException. We don't particularly mind doing that, but it would be nice to be able to distinguish between that scenario and other "unexpected scenarios". I could work toward a PR if people are still interested.

@niemyjski
Copy link
Collaborator

@marpstar that would be awesome :)

@niemyjski
Copy link
Collaborator

@marpstar were you able to create a pr for this?

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

No branches or pull requests

4 participants