-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
fix(auth): custom userPoolEndpoint
cannot be applied on the server-side
#13739
Conversation
Please ensure that this PR:
A repository administrator is required to review this change. |
packages/auth/src/foundation/core/cognitoUserPoolEndpointResolver.ts
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,6 @@ | |||
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. |
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.
General question - how do we feel about index files? I think I still like them for selectively exposing functions from a group (subpath/folder)
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.
It shortens import path on some occasions which is a nice way to organize code.
Though need to be care full import unexpected side effect?
e.g.
index.ts
module1.ts // <- has a side effect executes on module loads
module2.ts
I want to use a function provided from module2, if import from index.ts
, the side effect lives in module1 may get attached.
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.
Seems like a good reason to consider dropping the practice overall except for maybe exposing types and controlling top level exports 🤔
...ation/factories/serviceClients/cognitoIdentityProvider/createAssociateSoftwareTokenClient.ts
Outdated
Show resolved
Hide resolved
.../auth/src/foundation/factories/serviceClients/cognitoIdentityProvider/types/ServiceClient.ts
Outdated
Show resolved
Hide resolved
...ies/serviceClients/cognitoIdentityProvider/shared/serialization/buildUserPoolDeserializer.ts
Outdated
Show resolved
Hide resolved
packages/auth/__tests__/foundation/core/parsers/getRegion.test.ts
Outdated
Show resolved
Hide resolved
...serviceClients/cognitoIdentityProvider/shared/handler/cognitoUserPoolTransferHandler.test.ts
Outdated
Show resolved
Hide resolved
packages/auth/__tests__/foundation/core/parsers/getRegion.test.ts
Outdated
Show resolved
Hide resolved
...eClients/cognitoIdentityProvider/shared/serialization/buildEmptyResponseDeserializer.test.ts
Outdated
Show resolved
Hide resolved
...ories/serviceClients/cognitoIdentityProvider/shared/serde/createEmptyResponseDeserializer.ts
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,6 @@ | |||
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. |
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.
Seems like a good reason to consider dropping the practice overall except for maybe exposing types and controlling top level exports 🤔
import { cognitoUserPoolEndpointResolver } from '../../../foundation/cognitoUserPoolEndpointResolver'; | ||
|
||
export const createCognitoUserPoolEndpointResolver = | ||
({ endpointOverride }: { endpointOverride: string | undefined }) => |
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 not just making the endpointOverride
key optional instead of forcing to pass a value?
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.
See this comment, it answers this.
...ation/factories/serviceClients/cognitoIdentityProvider/createAssociateSoftwareTokenClient.ts
Show resolved
Hide resolved
d13d507
@@ -27,12 +27,12 @@ import { assertValidationError } from '../../../errors/utils/assertValidationErr | |||
import { AuthValidationErrorCode } from '../../../errors/types/validation'; | |||
import { AuthErrorCodes } from '../../../common/AuthErrorStrings'; | |||
import { cacheCognitoTokens } from '../tokenProvider/cacheTokens'; | |||
import { tokenOrchestrator } from '../tokenProvider'; |
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.
nit: unused?
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 pretty sure it's used at line 98
Description of changes
This PR re-organized the Cognito Identity service clients, and turn them into factory function. These factories expecting an
endpointResolver
to be injected as dependency. So they can be created within the Auth category API calls, and ensure it uses the always up-to-date endpoint information.Issue #, if available
#13650
Description of how you validated changes
Checklist
yarn test
passesChecklist for repo maintainers
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.