This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Stop putting a time caveat on access tokens#1656
Merged
Conversation
94d4790 to
d32a300
Compare
The 'time' caveat on the access tokens was something of a lie, since we weren't enforcing it; more pertinently its presence stops us ever adding useful time caveats. Let's move in the right direction by not lying in our caveats.
d32a300 to
1c4f05d
Compare
| @@ -810,6 +810,10 @@ def validate_macaroon(self, macaroon, type_string, verify_expiry, user_id): | |||
| else: | |||
| v.satisfy_general(lambda c: c.startswith("time < ")) | |||
Contributor
There was a problem hiding this comment.
Might as well remove the verify_expiry config option while you are at it.
Contributor
There was a problem hiding this comment.
and put a comment explaining why we aren't ever going to check the "time < " caveats.
Contributor
There was a problem hiding this comment.
But leave the v.satisfy_general(lambda c: c.startswith("time < ")) so that existing tokens will still work.
Contributor
There was a problem hiding this comment.
Except you can't remove the verify_expiry option because it's used in validate_short_term_login_token_and_get_user_id
Contributor
There was a problem hiding this comment.
But you probably want to add a comment to explain what's going on.
Contributor
|
LGTM |
Member
Author
|
test fails seem unrelated. |
richvdh
added a commit
that referenced
this pull request
Jul 29, 2019
The `expire_access_token` didn't do what it sounded like it should do. What it actually did was make Synapse enforce the 'time' caveat on macaroons used as access tokens, but since our access token macaroons never contained such a caveat, it was always a no-op. (The code to add 'time' caveats was removed back in v0.18.5, in #1656)
richvdh
added a commit
that referenced
this pull request
Jul 30, 2019
The `expire_access_token` didn't do what it sounded like it should do. What it actually did was make Synapse enforce the 'time' caveat on macaroons used as access tokens, but since our access token macaroons never contained such a caveat, it was always a no-op. (The code to add 'time' caveats was removed back in v0.18.5, in #1656)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 'time' caveat on the access tokens was something of a lie, since we weren't
enforcing it; more pertinently its presence stops us ever adding useful time
caveats.
Let's move in the right direction by not lying in our caveats.