feat: Update RFC#91 with new token format #105
Conversation
text/0091-ci-upload-tokens.md
Outdated
| if not token.startswith("sntrys_") or token.count('_') != 2: | ||
| return None | ||
|
|
||
| # Note: We add == to the end of the string, because we remove the base64 padding when generating the token |
There was a problem hiding this comment.
Why do we remove the padding when generating the token? Can we just keep the padding in place so that client-side decoding is simple?
There was a problem hiding this comment.
the idea is to have "nicer" tokens without the == in them, from a users perspective. I don't have a super strong feeling here, maybe we also leave this out as this is not the end of the token string anymore (as the secret is at the end) 🤔 It doesn't matter that much if there is == in the middle of the token I'd say.
There was a problem hiding this comment.
After giving it some more thought, I will adjust this to allow padding for the encoded payload, as it is in the middle of the token and there are also other special characters (e.g. / or -) in the base64 encoded string, it makes it easier to allow this. We just make sure to have no padding at the end of the secret.
mydea
force-pushed
the
fn/update-org-token-format
branch
from
63d8c3f
to
12e9a38
Compare
This PR adjusts the token format of the new org auth tokens from using JWT to a custom format based on base64 encoding. This should result in nicer endings of tokens, and also makes the tokens considerably shorter. Related to getsentry/rfcs#105 --------- Co-authored-by: Matthew T <matthew.trostel@sentry.io>
This PR updates RFC #91 with an adjusted token format. We did some experimentation and started implementation and noticed shortcomings of the JWT format, so we decided to change course here to a more simple base64 format.
Rendered RFC