-
Notifications
You must be signed in to change notification settings - Fork 72
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
Returning accounts go first in getUserInfo #483
base: main
Are you sure you want to change the base?
Conversation
This PR fixes the way an account is chosen as returning for getUserInfo: if approvedClients is available, that is considered the source of truth. Also, the returning list should list the returning accounts first, and then all the remaining accounts.
@bvandersloot-mozilla please take a look |
Ping |
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.
not sure if you were waiting for me here but lgtm
I noticed this PR is still relevant. Rebased since it was pretty old but still want to merge this. Anyone have any further comments? |
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.
Computing a secret bit and using it to re-sort a list returned to the webpage is not a good pattern. If we are going to alter the output, it should at least be observable why.
This is hard to work with. Is accounts[0]
previously used? accounts[n-1]
?
spec/index.bs
Outdated
@@ -1635,23 +1635,27 @@ When invoking the {{IdentityProvider/getUserInfo()}} method given an {{IdentityP | |||
{{DOMException}}. | |||
1. Let |accountsList| be the result of [=fetch the accounts list=] with |config|, |provider|, | |||
and |globalObject|. | |||
1. Let |hasReturningAccount| be false. | |||
1. For each |account| in |accountsList|: | |||
1. Let |isReturningAccount| be a new [=list=] of the same length as |accountsList|, with all |
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.
Should this be on the accounts, rather than adding a new boolean?
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.
The accounts are dictionaries parsed from the IdP's response, so we cannot add properties to them.
1. Let |notReturningUserInfos| be a new [=list=]. | ||
1. For each |i| from 0 to the length of |accountsList| minus 1: | ||
1. Let |account| be |accountsList|[|i|]. | ||
1. Let |userInfo| be an {{IdentityUserInfo}} with the following values: |
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.
Or at least in the IdentityUserInfo? that way we can expose it to the webpage
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 seems like a broader change (adding a webexposed member to the IdentityUserInfo. The goal of this PR is to fix a bug in the existing returned values.
The idea is that |
|
You can. |
This PR fixes the order of returned accounts in
getUserInfo()
. The returning list should list the returning accounts first, and then all the remaining accounts.Fixes #625
Preview | Diff