Listen for storage to receive auth hash from popup #935
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently,
initLoginFlowInPopup
method is expecting to receive a message from the popup viapostMesage
by subscribing to it via:Unfortunately this doesn't always work: when the auth provider is on a different domain and the auth process includes redirects within the popup to even more upstream authentication authorities on a third domain and the flow eventually comes back to the original application domain, the popup no longer "remembers" its
window.opener
. AFAIU this is done for security reasons.. This means that the popup has no one topostMessage
to, and the parent application is left there waiting forever.This MR suggests adding a storage event fallback. The parent application launches the popup and listens for two sources instead of one:
'message'
events (received bypostMessage
on the other side) and'storage'
events, which the popup can fallback to if it has no parent or opener to refer to.Here's an example of the
silent-refresh.html
to support the idea: