Skip to content

OAuthException in a decorator can't be handled #12

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

Open
jace opened this issue Aug 23, 2011 · 2 comments
Open

OAuthException in a decorator can't be handled #12

jace opened this issue Aug 23, 2011 · 2 comments

Comments

@jace
Copy link

jace commented Aug 23, 2011

The authorized_handler method raises OAuthException if the OAuth process fails. However, since this method is a decorator, there's no way to write an exception handler that can display a friendly error message to the user. Instead, the user sees a 500 internal server error.

Relevant code: https://github.com/mitsuhiko/flask-oauth/blob/master/flaskext/oauth.py#L305

@aviflax
Copy link

aviflax commented Apr 26, 2013

+1

I had to manually apply the decorator and it was a real pain.

I have 2 suggestions:

  1. Split the decorators into 2 methods: one for the functionality, one which makes it a decorator. That way if one wanted to, one could easily just call the “functionality” method and just use its return value.
  2. Have the decorators catch all exceptions which occur before calling the wrapped function, and if an exception is raised, just pass it to the wrapped function in a specific named argument. (Similar to Node callbacks.) The wrapped functions can then just check whether the error arg is not None and if so deal with it.

@yannk
Copy link

yannk commented Sep 3, 2013

I wrapped the decorator with another decorator (trapping this very exception) but it's not ideal, I agree. It would be nice to have a authorize() method returning the data, or throwing whatever exception.

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

No branches or pull requests

3 participants