Why configure the JWT location statically?

[sisp]

Hi,

I've been wondering whether there's a particular reason why you decided to have a configuration option that determines the location of the JWT when checking a request with jwt_required. Instead, wouldn't it be better to pass a list of locations to the decorator?

@jwt_required(['cookie', 'header'])
def view():
    ...

This decorator would look for a cookie first and, if there's no cookie with the JWT, also check the header. Of course, only checking one of the two would be possible, too, and there could be a configurable default location.

What do you think?

[vimalloc]

I really like the idea of being able to check multiple locations. It would be great for scenarios where you wanted to use cookies on your website, and headers on your mobile application (as an example). I think I have a TODO somewhere in the code base about this.

I'm not sure if I like having this option it in the @jwt_required decorator though, as it adds a lot of extra typing you would need to do for each protected endpoint (and have more surface area for typos) . Additionally, I'm not convinced there would be endpoints that you only wanted to be able to access via certain JWT location (have one endpoint only accepting cookies and another only accepting headers). I imagine most endpoints that you only want some people accessing would instead be limited by identity or role. If you disagree with this, I would love to hear your arguments why!

How would you feel about allowing lists to be passed to JWT_TOKEN_LOCATION, so that all of these would become valid:

app.config['JWT_TOKEN_LOCATION'] = 'cookies'
app.config['JWT_TOKEN_LOCATION'] = 'headers'
app.config['JWT_TOKEN_LOCATION'] = ['cookies']
app.config['JWT_TOKEN_LOCATION'] = ['headers']
app.config['JWT_TOKEN_LOCATION'] = ['cookies', 'headers']

Thanks for the feedback!

[sisp]

I think you're right about not needing different JWT locations per endpoint. I was thinking of a mixed Flask app consisting of frontend blueprints and API blueprints. The frontend blueprints would likely use cookies, perhaps headers, and the API blueprint would use headers but most likely not cookies, so I thought only allowing headers for the API would be appropriate. But I guess it wouldn't hurt to accept cookies for the API blueprint, too, even if they are never be used.

Allowing lists to be passed to JWT_TOKEN_LOCATION would be a great feature to add.

[vimalloc]

Ok, I'll start with just adding the ability to have lists in JWT_TOKEN_LOCATION, and we can evaluate how that works and go from there.

It may take a few days to get this pushed out, but I'll try to have a new release for this pushed out early next week.

Cheers!

[sisp]

Cool, thanks a lot!

[vimalloc]

This is released as version 1.2.0. Let me know if you have any problems with it.

Cheers!