allow other authorization type to pass

[philloooo]

if a flask app supports multiple authorization mechanisms, eg: JWT and hmacv4, how should I use this library?
From what I see in the decorator, it raises execption as long as it finds the authorization type doesn't match what's configured.
Can you support another setting flag to allow alternative authorization type, so that the jwt_optional just silently do nothing if the type is not bearer?

[vimalloc]

Can you support another setting flag to allow alternative authorization type, so that the jwt_optional just silently do nothing if the type is not bearer?

If you just want to change the header name that sends in the JWT, you can do that with the JWT_HEADER_NAME and JWT_HEADER_TYPE options (http://flask-jwt-extended.readthedocs.io/en/latest/options.html#header-options). By default JWT_HEADER_TYPE is Authorization, and JWT_HEADER_TYPE is Bearer.

If you're saying you want it to not error out when using @jwt_optional if we get an authorization header that doesn't match the type this extension is expecting, I could look into adding a new flag to control that. However, there might be a simpler way to work around this. Do you control whatever frontend is sending the JWTs to your application? If there is a conflict between two sources that want to send in data from an authorization header, you could always change the JWT_HEADER_NAME for this extension and send it in via a header name different then Authorization. There is no technical reason why that header has to be used, it is just a convention.

If that doesn't work for you, let me know, and I'll look closer at this and see if something could be done without too much trouble on this extension.

Cheers.

[philloooo]

Thanks for the quick response!
I agree that there is technically no reason to not use a different header name, but I would like to adhere to the best practices.
Afaik the header_type was suggested to be in the Authorization header so that we can distinguish different algorithms, and that makes services that support multiple auth mechanisms work. So it would be great if a new flag can be added to control that.

[vimalloc]

Fair enough. I'll poke at it this weekend and come up with something.

Cheers.

[philloooo]

thanks!!

[vimalloc]

Got this released in version 3.3.1.

Instead of another flag, I just set it up to always ignore InvalidHeaderError in @jwt_optional. This sounded like the more sane thing to do, I can't imagine any is actively relying on getting that error back if they are sending in differently formatted authorization headers to a @jwt_optional endpoint. Let me know if you run into any issues with this.

Cheers.