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.

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

Add more flexible and complete verification options #127

Closed
mark-adams opened this issue Mar 29, 2015 · 4 comments · Fixed by #131
Closed

Add more flexible and complete verification options #127

mark-adams opened this issue Mar 29, 2015 · 4 comments · Fixed by #131
Milestone

Comments

@mark-adams
Copy link
Contributor

I was thinking that it might be useful for us to implement more flexible verification options.

I propose something like this:

def decode(token, secret, options=None)

where options is a dict that looks something like this:

options = {
   'verify_signature': True,
   'verify_exp': True,
   'verify_nbf': True,
   'verify_iat': True,
   'verify_aud`: True
}

This is similar to what ruby-jwt does
We could make it where options could be specified globally (at the PyJWT object level) or as an override argument to decode()

@jpadilla
Copy link
Owner

jpadilla commented Apr 4, 2015

@mark-adams yeah I can see how this can be useful. For example that #129 use case could just set verify_aud to False.

michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
michaeldavis-wf pushed a commit to michaeldavis-wf/pyjwt that referenced this issue Apr 7, 2015
@mark-adams
Copy link
Contributor Author

I'll take a look

@michaeldavis-wf
Copy link
Contributor

@mark-adams I know timelines are to be taken with a grain of salt, but do you have a guesstimate on how long 1.1.0 might be? I would love to be able to pull in the changes from this PR.

If it is going to be too long, would it be possible to cut a 1.0.2 release with the current master?

@mark-adams
Copy link
Contributor Author

Moved this convo to #137

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants