Add flexible and complete verification options

[michaeldavis-wf]

This adds the ability to use a more flexible option dictionary. The options dictionary can be specified at the PyJWT object level or as an override passed directly into decode()

Attempts to fix #127

[jpadilla]

Oh yeah, this looks good to me.

@mark-adams would like your feedback, since you created #127.

[johnlockwood-wf]

I would like to see these abbreviations expanded. The only reason they are abbreviated in the standard is to reduce the amount of data transmitted. Here it just serves to obfuscate.

[johnlockwood-wf]

How many people will choose to solve, non-verification messages by figuring out they can set all of these to False rather than taking the time to understand what it all means?

[michaeldavis-wf]

The only way to avoid consumers skipping verification is to completely disallow it, which ignores a huge number of use cases that need to turn off various checks.

[mark-adams]

I support keeping these abbreviated so they are consistent with the claim names. This is similar to how the Ruby JWT library does things. I think we should keep them the way they are.

Regarding @johnlockwood-wf's comment about setting everything to False; I'm not sure we can avoid people being stupid with their usage. Defaulting to secure (and to the standard) is the best behavior here.

[johnlockwood-wf]

they should at least be labeled with expansions, or have a "constants" class that labels the keys, such as:

class CLAIMS_KEYS(object):
    class VERIFY(object):
        EXPIRATION = 'verify_exp'
        ISSUED_AT = 'verify_iat'

[mark-adams]

Also, @michaeldavis-wf, make sure you add yourself to the AUTHORS file

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling e62df13 on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling e62df13 on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling e62df13 on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 13d2420 on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 13d2420 on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[johnlockwood-wf]

what do you think about the keyword being, verification_options, so they are well categorized.

[mark-adams]

There's no reason why we couldn't use options= for other options later. I feel like verification_options would restrict what we could do with this argument unnecessarily.

In addition, all the current options start with verify_ so I feel like it'd be a bit redundant to call it verification_options.

[johnlockwood-wf]

Grouping arguments into a category is better than having a lot of uncategorized arguments. If there are more unrelated types of arguments in the future, they could be added to another group.

[johnlockwood-wf]

and to reduce redundancy, the verification_options dict could leave out the verify_ prefix of the keys.

[johnlockwood-wf]

verify_claims = {'exp': False, 'aud': False}

[johnlockwood-wf]

As maintainers it is also easier to commit to a more restricted change to the interface.

[mark-adams]

In the long-run, I'd rather add some sort of custom extensibility point (read: callable) that you could pass for additional validations on top of those provided by the library.

I don't feel like we're at risk here of adding "too many unrelated arguments or options" even though I do understand your concern. We aren't going to add all sorts of crazy willy-nilly validations that will require new options; our main focus is on parity with the validations with the JWT spec and I can't see it requiring us to add too many more options here outside of what's already in the spec. A couple more may be added from some additional work we'll probably wind up doing with JWK, but I think the number of new options would be very limited.

[mark-adams]

I don't have a problem discussing more ideas in future PRs but I believe this is better than what we currently have for sure.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 0ab287b on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 0ab287b on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[mark-adams]

@michaeldavis-wf Last thing and I'm cool with merging this... can you add something to the CHANGELOG?

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 6e6046c on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 6e6046c on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 6e6046c on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[coveralls]

Coverage increased (+0.01%) to 99.76% when pulling 6e6046c on michaeldavis-wf:options-dict into a2601ad on jpadilla:master.

[michaeldavis-wf]

@mark-adams @jpadilla Would it be possible to cut a release with this functionality in it, or possibly after #132 goes in?

[jpadilla]

@mark-adams I'm fine with a new release whenever you want. You could create a PR with the version bump, etc and I'll go ahead and publish the release.

[mark-adams]

Cool. I'll try to wrap things up tonight. I had a couple small changes I wanted to make