feat: Update RFC#91 with new token format by mydea · Pull Request #105 · getsentry/rfcs

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

mydea · 2023-06-21T08:48:20Z

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

mdtro · 2023-06-21T14:13:01Z

+ 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


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?

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.

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.

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>

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

feat: Update RFC#91 with new token format
d0c8f3f

mydea requested a review from mitsuhiko June 21, 2023 08:48

mydea self-assigned this Jun 21, 2023

mydea requested a review from mdtro June 21, 2023 08:49

mydea mentioned this pull request Jun 21, 2023
feat(org-tokens): Adjust token format from JWT getsentry/sentry#51341
Merged

mydea added 2 commits June 21, 2023 11:19

feedback from michi
72ae0b1

better secret generation
f441fa8

markstory reviewed Jun 21, 2023
View reviewed changes

Comment threadtext/0091-ci-upload-tokens.md

mdtro reviewed Jun 21, 2023
View reviewed changes

mydea added 2 commits June 21, 2023 17:10

use secrets
d247a81

avoid paddingless base64
12e9a38

mydea force-pushed the fn/update-org-token-format branch from 63d8c3f to 12e9a38Compare June 22, 2023 10:48

mydea merged commit a018ea4 into mainJun 26, 2023

mydea deleted the fn/update-org-token-format branch June 26, 2023 09:19

oioki mentioned this pull request Sep 25, 2023
Improved API Tokens #32
Open

Uh oh!

Uh oh!

Conversation

mydea commented Jun 21, 2023

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

mydea commented Jun 21, 2023

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

mydea commented Jun 21, 2023

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

mydea commented Jun 21, 2023

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants