-
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(singleton): allow oauth listener to be called with the latest config #13642
base: main
Are you sure you want to change the base?
Conversation
// The setTimeout will only be called as long as an oAuthLister and oauth config | ||
// are defined. The code executed by the time out will be only fired once. |
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.
This sounds like it only works with certain preconditions, e.g. assuming Amplify.configure()
gets called back to back. While this trick seemed to be working, I'm hesitant to make this a solution...
With Amplify Gen2, amplify_outputs.json
can be overridden from the backend.ts
(reference). With Amplify Gen1, should be able to change the url in amplifyconfiguration.json
as well, would be these be legit workarounds to solve what the PR is trying to solve?
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 have to echo this sentiment. When I looked at this PR this was my initial concern as well. Code after the configure call that may have previously executed after the this.oAuthListener
call was made may now execute after the call due to it being pulled out of the current execution cycle. While I'm not certain that is practically concerning, it feels quite risky.
// The setTimeout will only be called as long as an oAuthLister and oauth config | ||
// are defined. The code executed by the time out will be only fired once. |
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 have to echo this sentiment. When I looked at this PR this was my initial concern as well. Code after the configure call that may have previously executed after the this.oAuthListener
call was made may now execute after the call due to it being pulled out of the current execution cycle. While I'm not certain that is practically concerning, it feels quite risky.
amplify: AmplifyClass, | ||
config: AuthConfig['Cognito'], | ||
oAuthListener: OAuthListener, |
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.
Making this pure would make sense if it were removed completely from the class, but since it is a private member of the class, this seems confusing. For example, it's not really clear to me why oAuthListener
is passed separately from this
. The clearListenerTimeout
is then also tacked onto the instance but it's obfuscated here.
Description of changes
Amplify.configure
will calloAuthListener
and it will pass the Auth config. ThisoAuthListener
is responsable for completing an OAuth flow. However whenAmplify.configure
is called more than 1 time, theoAuthListener
will be called only with the first Auth config.This fix makes sure the
oAuthListener
is called only and only if a valid OAuthconfig
andoAuthListener
are already defined. And ensures theoAuthListener
is called with the latest config of Amplify.Before
Amplify.configure
with config1 ->Amplify.configure
with config2 -> calloAuthListener
with config1After
Amplify.configure
with config1 ->Amplify.configure
with config2 -> calloAuthListener
with config2Issue #, if available
#12849
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.