Unexpected change in 4.4.0 (verify_type)

[DavidMStraub]

Investigating some failing unit tests, I found a surprising change in 4.4.0, which is the new verify_type argument in jwt_required. I say surprising because the behaviour up until 4.3.1 was equivalent to verify_type=True, but the default from 4.4.0 is verify_type=False. This implicitly changes the behaviour in all libraries using this decorator. Adding an explicit verify_type=True means not being backward compatible with versions before 4.4.0.

Is this behaviour intentional?

Naively, I would say it's lower security because if somebody steals my access token (e.g. because I accidentally share an image URL with a token in it), with verify_type=False the thief can get a refresh token and gain long term (default: 30 days) access. With verify_type=True, they loose access after (default) at most 15 minutes. Am I missing something?

So I would have found it more logical to keep the existing behaviour as the default and let users opt in to the new behaviour.

[vimalloc]

Oh no! The goal with verify_type was not to introduce a breaking change. I must have gotten mixed around with this one. Sorry! I'll take a closer look when I'm home today, and get a bug fix release out stat.

Thank you for the report!

[vimalloc]

So digging into this more, it looks like the @jwt_required decorator does have verify_type properly set to True, but if you're using the underlying verify_jwt_in_request() function directly, that was accidentally set to verify_type=False. Oops!

Got that fixed up, and getting a new released pushed out now. Thanks!