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

feat: add token id optional field to disposable tokens #968

Merged
merged 5 commits into from
Oct 19, 2023

Conversation

pratik151192
Copy link
Contributor

@pratik151192 pratik151192 commented Oct 16, 2023

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 a tokenID field there. Instead, added as a new props for that API.

PR #1 for https://github.com/momentohq/dev-eco-issue-tracker/issues/511

@pratik151192 pratik151192 marked this pull request as ready for review October 17, 2023 00:26
@pratik151192
Copy link
Contributor Author

@cprice404 I notice that the method generateAPIKey too accepts a tokenID but I didn't club it in this PR as the ticket was scoped to the disposableToken API. LMK if you want me to club here though.

Comment on lines 149 to 153
if (tokenID.length > 64) {
throw new InvalidArgumentError(
'TokenID must be less than or equal to 64 characters.'
);
}
Copy link
Contributor Author

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.

Copy link
Contributor

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,
Copy link
Contributor

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?

Copy link
Contributor Author

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;
        });

anitarua
anitarua previously approved these changes Oct 17, 2023
Copy link
Contributor

@anitarua anitarua left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@pratik151192
Copy link
Contributor Author

@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

@cprice404
Copy link
Contributor

@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?

@cprice404
Copy link
Contributor

@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

Copy link
Contributor

@cprice404 cprice404 left a 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) {
Copy link
Contributor

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) {
Copy link
Contributor

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;
Copy link
Contributor

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;
Copy link
Contributor

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

Comment on lines 149 to 153
if (tokenID.length > 64) {
throw new InvalidArgumentError(
'TokenID must be less than or equal to 64 characters.'
);
}
Copy link
Contributor

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

@cprice404
Copy link
Contributor

@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

the latest CI failure looks more like a bug than a transient issue; i don't see any timeouts or anything

Copy link
Contributor

@anitarua anitarua left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@pratik151192 pratik151192 merged commit b7ed3bd into main Oct 19, 2023
13 checks passed
@pratik151192 pratik151192 deleted the token-id-disposable-tokens branch October 19, 2023 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants