-
Notifications
You must be signed in to change notification settings - Fork 373
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
feat(auth): Add ability to link a federated ID with the updateUser()
method.
#770
Conversation
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.
LGTM overall.
@@ -265,6 +265,8 @@ function validateCreateEditRequest(request: any, uploadAccountRequest: boolean = | |||
phoneNumber: true, | |||
customAttributes: true, | |||
validSince: true, | |||
// Pass linkProviderUserInfo only for updates (i.e. not for uploads.) | |||
linkProviderUserInfo: !uploadAccountRequest, |
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.
Add deleteProvider as well?
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's already present (line 263) since it was used previously to remove phone auth entries.
src/auth/auth-api-request.ts
Outdated
@@ -410,6 +412,11 @@ function validateCreateEditRequest(request: any, uploadAccountRequest: boolean = | |||
validateProviderUserInfo(providerUserInfoEntry); | |||
}); | |||
} | |||
|
|||
// linkProviderUserInfo must be a (single) UserInfo 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.
UserProvider?
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.
Done.
} | ||
|
||
if (typeof(request.providersToDelete) !== 'undefined') { | ||
if (!validator.isArray(request.deleteProvider)) { |
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.
Isn't this check redundant, considering the condition gets checked at validation?
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.
deleteProvider
might not yet exist. (Or technically, the end user could set it to anything they like if they're using javascript rather than typescript.)
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 will achieve the same result without the if condition I think:
request.deleteProvider = (request.deleteProvider || []).concat(request.providersToUnlink);
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 user could set this value to anything they like which could interact badly:
request.deleteProvider = "foo"
request.providersToUnlink = [ "phone", "email" ]
request.deleteProvider = (request.deleteProvider || []).concat(request.providersToUnlink);
console.log(request.deleteProvider)
> ["foophone", "email"]
Such use would be pretty questionable since deleteProvider
doesn't show up in the UpdateRequest interface... though that doesn't stop the user from setting it anyways for their own purposes. (Although we modify it here, we also take a copy first, so this won't impact the user's copy.) Given that, it seems easiest to just check to see if it's an array first.
Thinking about it a bit more though, another alternative would be to just set deleteProvider to undefined (or []) after we take the copy, thus ensuring any value that the user sets can't interfere with this value.
I've left it as is for now, though could switch to the alternative if you'd prefer.
src/auth/user-record.ts
Outdated
/** | ||
* The user identifier for the linked provider. | ||
*/ | ||
uid?: 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.
providerUid?
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's just uid
in the other ports. Combined with the interface name (which contains 'provider'), I think that's probably ok.
src/index.d.ts
Outdated
providerToLink?: UserProvider; | ||
|
||
/** | ||
* Unlinks this user from the specified federated providers. |
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.
s/federated providers/providers?
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.
Done. (Also above)
test/integration/auth.spec.ts
Outdated
}); | ||
|
||
it('can link/unlink with a federated provider', async () => { | ||
const federatedUid = 'google_uid_' + generateRandomString(10); |
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.
Could this be changed to googleUid/googleFederatedUid, to avoid an unnecessary confusion between federatedUid and providerUid?
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.
Done.
test/unit/auth/auth.spec.ts
Outdated
it('should be rejected given an empty providersToDelete list', () => { | ||
expect(() => { | ||
auth.updateUser(uid, { | ||
providersToDelete: [], |
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.
Could this be a no-op instead?
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.
You're right; there's not really any reason to reject this. I've moved the test to an integration test (to ensure the backend is happy with the noop. If that ever changes, we can add code to special case this.)
test/unit/auth/auth.spec.ts
Outdated
}); | ||
}); | ||
|
||
it('specifying both phoneNumber=null and providersToDelete=phone should be rejected', () => { |
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: does this need to be reject?
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 don't know. It does indicate a slight misuse of our API as there's not really any situation where the user should be deleting both by setting phoneNumber=null and also by adding phone to providersToDelete. OTOH, the user's intent is clear in this case. See also the comment in the implementation (src/auth/auth.ts:updateUser:~313)
I'm inclined to be a bit conservative and reject this situation as an error and then relax it later if necessary. But am also willing to be convinced otherwise. We'll get a few more reviews before this lands, so we can probably just go with the consensus that results from that.
I've left this alone for now.
caac5bc
to
c79f42d
Compare
@@ -961,6 +968,31 @@ export abstract class AbstractAuthRequestHandler { | |||
'Properties argument must be a non-null object.', | |||
), | |||
); | |||
} else if (validator.isNonNullObject(properties.providerToLink)) { |
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.
Aren't the validations at validateCreateEditRequest sufficient? Seems like the validation is added in two places.
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.
(Missed this comment, sorry!)
IIUC, the parameters are slightly different, so it doesn't quite work. (eg rawId). Some refactoring could be done though... I've added a TODO.
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
Hi @rsgowman. Is this PR ready for a round of review? Looks like the build failed due to an out of date API report. You might wan to run |
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. ℹ️ Googlers: Go here for more info. |
7f077e8
to
a3f8f69
Compare
No description provided.