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.

Sign up for GitHub

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

Jump to bottom

@jwt_required does not work with the OPTIONS method #475

Open
stackp opened this issue Apr 13, 2022 · 4 comments
Open

@jwt_required does not work with the OPTIONS method #475

stackp opened this issue Apr 13, 2022 · 4 comments

Comments

@stackp
Copy link

stackp commented Apr 13, 2022 •
edited

Hello,

Thanks for the great work !

With the OPTIONS HTTP method, a confusing error message is raised, stating that @jwt_required() was not called, although it was called:

"You must call @jwt_required() or verify_jwt_in_request() "

Here is a way to reproduce the issue :

from flask import Flask, jsonify
from flask_jwt_extended import get_jwt_identity, jwt_required, JWTManager

app = Flask(__name__)
app.config["JWT_SECRET_KEY"] = "super-secret"
jwt = JWTManager(app)

@app.route("/", methods=["GET", "OPTIONS"])
@jwt_required(optional=True)
def protected():
    current_user = get_jwt_identity()
    return "hello", 200


if __name__ == "__main__":
    app.run()
$ curl -X OPTIONS http://0.0.0.0:5000/ -i 
HTTP/1.0 500 INTERNAL SERVER ERROR
Content-Type: text/html; charset=utf-8
Content-Length: 290
Server: Werkzeug/2.0.2 Python/3.7.11
Date: Wed, 13 Apr 2022 07:55:36 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>500 Internal Server Error</title>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.</p>

2022-04-13 09:55:36,725] ERROR in app: Exception on / [OPTIONS]
Traceback (most recent call last):
  File "/***/venv/lib/python3.7/site-packages/flask/app.py", line 2073, in wsgi_app
    response = self.full_dispatch_request()
  File "/***/venv/lib/python3.7/site-packages/flask/app.py", line 1518, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/***/venv/lib/python3.7/site-packages/flask/app.py", line 1516, in full_dispatch_request
    rv = self.dispatch_request()
  File "/***/venv/lib/python3.7/site-packages/flask/app.py", line 1502, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args)
  File "/***/venv/lib/python3.7/site-packages/flask_jwt_extended/view_decorators.py", line 127, in decorator
    return current_app.ensure_sync(fn)(*args, **kwargs)
  File "test_app.py", line 11, in protected
    current_user = get_jwt_identity()
  File "/***/venv/lib/python3.7/site-packages/flask_jwt_extended/utils.py", line 58, in get_jwt_identity
    return get_jwt().get(config.identity_claim_key, None)
  File "/***/venv/lib/python3.7/site-packages/flask_jwt_extended/utils.py", line 25, in get_jwt
    "You must call `@jwt_required()` or `verify_jwt_in_request()` "
RuntimeError: You must call `@jwt_required()` or `verify_jwt_in_request()` before using this method
127.0.0.1 - - [13/Apr/2022 09:55:36] "OPTIONS / HTTP/1.1" 500 -
@vimalloc
Copy link
Owner

This is happening because in most cases, OPTIONS is used as a preflight CORS check that happens automatically by the web browser, and when that happens the browser wont be sending a JWT with the request, which causes the preflight check to always fail. To account for that, this extension is configured to ignore jwt checks if for OPTION requests here: https://github.com/vimalloc/flask-jwt-extended/blob/master/flask_jwt_extended/config.py#L277-L279

If this is a use case you need to support, I would be more then happy to have an HTTP_EXEMPT_METHODS flask configuration option option put in place, which would allow you to override this behavior. What is your use case for needing an explicit OPTIONS request?

@stackp
Copy link
Author

stackp commented Apr 15, 2022

Hi @vimalloc, thanks for your reply.

It is not a use case I need to support; this error is raised in our prod app a few times a week, and I was confused by the message trying to trace it. I am not sure why some clients send an OPTIONS request here, as there is no cross-origin situation in our app.

Here is how the app is set up, you can see that the error is raised before any Flask route is entered, and therefore before any check on the HTTP method is done.

@jwt_required(optional=True)
def get_user_id():
    return get_jwt_identity()

@app.before_request
def before_request():
    g.user_id = get_user_id()

@app.errorhandler(jwt.exceptions.PyJWTError)
@app.errorhandler(flask_jwt_extended.exceptions.JWTExtendedException)
def handle_expired_token(error):
    # Exceptions raised by @jwt_required(optional=True)
    logging.warning("Invalid JWT token", exc_info=True)
    unset_jwt_cookies(resp)
    return unauthorized()

I would have expected get_jwt_identity() to return None as optional=True is passed and no JWT is present. Wouldn't that be the correct behavior ?

Otherwise, I can check in my code if the method is OPTIONS, and force g.user_id = None in that case, without calling get_jwt_identity().

Thanks!

@vimalloc
Copy link
Owner

vimalloc commented Jun 1, 2022

Sorry for the late reply!

I would have expected get_jwt_identity() to return None as optional=True is passed and no JWT is present. Wouldn't that be the correct behavior

It would be, except that the entire callback chain is short circuited if it is an OPTIONS request (https://github.com/vimalloc/flask-jwt-extended/blob/master/flask_jwt_extended/view_decorators.py#L85-L86). The reason for that is otherwise CORS would break for an endpoint that had optional=False because the preflight OPTIONS request would return a 4xx code instead of a 200.

We could update that to not short circuit if optional=True and it's an OPTIONS request. I don't know if that really provides much value, but I'm not opposed to making that change. Thoughts?

@stackp
Copy link
Author

stackp commented Jun 2, 2022 •
edited

Hey! Thanks for your reply.

We could update that to not short circuit if optional=True and it's an OPTIONS request. I don't know if that really provides much value, but I'm not opposed to making that change. Thoughts?

That's the behavior I would expect from the decorator, though I agree it's quite an edge case. So, if it's an easy fix, then why not. ;)

For the record, I've added a condition in my code to not attempt to call get_jwt_identity()when method == 'OPTIONS'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@vimalloc @stackp