-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: add token id optional field to disposable tokens #968
Conversation
@cprice404 I notice that the method |
if (tokenID.length > 64) { | ||
throw new InvalidArgumentError( | ||
'TokenID must be less than or equal to 64 characters.' | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had thought to encode
the string and check the byte length in UTF-8 or something so lmk if this seems less potent that that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine
const request = new token.token._GenerateDisposableTokenRequest({ | ||
expires: expires, | ||
auth_token: this.creds.getAuthToken(), | ||
permissions: permissions, | ||
token_id: tokenID, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can the proto accept an undefined tokenID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
constructor(data?: any[] | {
expires?: _GenerateDisposableTokenRequest.Expires;
auth_token?: string;
permissions?: dependency_1.permission_messages.Permissions;
token_id?: string;
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
@anitarua @cprice404 unless am seeing it wrong, looks like the last 3 CIs failed on one or more tests unrelated to the PR. This particularly started happening after I added 2 new auth tests which don't seem to be related to integ tests. But would love another eye; I am afraid if this might be another Azure tipping point for something |
this seems really different from prev failures in that it's data plane (afaik all the azure things happened on control plane), plus if this is running on osx i'm not sure it's even using azure. Did you spot check the server metrics? |
I'm gonna kick the failed CI jobs one more time just to rule out something weird going on yesterday |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a few nits!
@@ -208,10 +211,22 @@ export class InternalAuthClient implements IAuthClient { | |||
return new GenerateDisposableToken.Error(normalizeSdkError(err as Error)); | |||
} | |||
|
|||
const tokenID = disposableTokenProps?.tokenID; | |||
if (tokenID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
javascript has very liberal definitions for "truthiness", so it's always better to be very explicit about the condition you are checking for. In this case I think it would be !== undefined
.
@@ -213,6 +216,18 @@ export class InternalWebGrpcAuthClient< | |||
|
|||
request.setPermissions(permissions); | |||
|
|||
const tokenID = disposableTokenProps?.tokenID; | |||
if (tokenID) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same nit about explicit condition check here
@@ -208,10 +211,22 @@ export class InternalAuthClient implements IAuthClient { | |||
return new GenerateDisposableToken.Error(normalizeSdkError(err as Error)); | |||
} | |||
|
|||
const tokenID = disposableTokenProps?.tokenID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
supernit: I think the idiomatic casing for this variable name in TS/JS would be tokenId
. I don't really care about it here for a local var, but we want to be deliberate in the props object since that is effectively public API.
@@ -77,6 +77,10 @@ export type DisposableTokenScope = | |||
| PredefinedScope | |||
| DisposableTokenCachePermissions; | |||
|
|||
export interface DisposableTokenProps { | |||
tokenID?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here - I think we want tokenId
for this public interface unless you have some style reference that suggests otherwise
if (tokenID.length > 64) { | ||
throw new InvalidArgumentError( | ||
'TokenID must be less than or equal to 64 characters.' | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine
the latest CI failure looks more like a bug than a transient issue; i don't see any timeouts or anything |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
Added token id as optional field (within an optional props) to disposable tokens API. The object
DisposableTokenScope
is encapsulated with all kinds of permission policies that we can provide, and it didn't seem clean to add atokenID
field there. Instead, added as a new props for that API.PR #1 for https://github.com/momentohq/dev-eco-issue-tracker/issues/511