-
Notifications
You must be signed in to change notification settings - Fork 2.2k
refactor(amazon-cognito-identity-js): refactor issue 8969 better typings #9935
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
base: main
Are you sure you want to change the base?
refactor(amazon-cognito-identity-js): refactor issue 8969 better typings #9935
Conversation
+1 |
Hey @Yoshiitaka , |
@Yoshiitaka , |
@chintannp |
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.
@Yoshiitaka thanks for this PR,
I have some concerns with typing some information that is available for getters, Another big concern is that attributes
and token
payload can be configured on the UserPool and could break the type.
What do you think?
payload: { | ||
sub: string; | ||
email_verified: boolean; | ||
iss: string; | ||
phone_number_verified: boolean; | ||
'cognito:username': string; | ||
given_name: string; | ||
origin_jti: string; | ||
aud: string; | ||
event_id: string; | ||
token_use: string; | ||
auth_time: number; | ||
phone_number: string; | ||
exp: number; | ||
iat: number; | ||
family_name: string; | ||
jti: string; | ||
email: 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.
A problem here is that this payload can modified ona userpool lambda trigger
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.
hmm...
In other words, does this place have to be as follows, not a strict type?
payload: { [key: string]: any };
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.
Correct
|
||
export interface CognitoAccessToken { | ||
jwtToken: string; | ||
payload: { |
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.
A the problem here is that decodePayload
return type is { [id: string]: any }
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.
hmm..
In other words, does this place have to be as follows, not a strict type too?
payload: { [key: string]: any };
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.
Interesting, the interface could be more restricted. I need to verify if those claims are same across every userpool
attributes: { | ||
email: string; | ||
email_verified: boolean; | ||
family_name: string; | ||
given_name: string; | ||
phone_number: string; | ||
phone_number_verified: boolean; | ||
sub: 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.
those got lazily load, and after that those are available, the other problem is that a user can have more attributes
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.
In that case, I began think that it is better not to create strict type information for Cognito User attributes.
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 agree, do you want to revert that change?
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.
Thank you for comment. yes, revert this changes.
public clockDrift: number; | ||
public idToken: CognitoIdToken; | ||
public accessToken: CognitoAccessToken; | ||
public refreshToken: CognitoRefreshToken; | ||
|
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.
why do you need to expose this values if there are already getters?
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'm see... That is as you pointed out.
there are already created the getter,
there was no need to expose public values.
Thank you :)
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.
Do you want to revert that change?
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, revert this changes too.
@Yoshiitaka, In order to get this change out quickly, Can you please review and address the feedback provided by @elorzafe ? |
@elorzafe Certainly, I was understood that the token payload may break the mold as you pointed out. |
@chintannp |
@Yoshiitaka , Can you address the feedback provide by @elorzafe ? |
@chintannp |
Codecov Report
@@ Coverage Diff @@
## main #9935 +/- ##
=======================================
Coverage 84.40% 84.40%
=======================================
Files 258 258
Lines 18698 18698
Branches 4021 4021
=======================================
Hits 15782 15782
Misses 2826 2826
Partials 90 90 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
5b68474
to
66bfe31
Compare
When I use |
Issue ##8969,
Better type definitions for amazon-cognito-identity-js.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.