Skip to content
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

Merged
merged 14 commits into from
Feb 9, 2021

Conversation

rsgowman
Copy link
Member

No description provided.

@rsgowman rsgowman assigned rsgowman and nrsim and unassigned rsgowman Jan 20, 2020
@rsgowman rsgowman requested a review from nrsim January 20, 2020 21:37
Copy link
Contributor

@nrsim nrsim left a 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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add deleteProvider as well?

Copy link
Member Author

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.

@@ -410,6 +412,11 @@ function validateCreateEditRequest(request: any, uploadAccountRequest: boolean =
validateProviderUserInfo(providerUserInfoEntry);
});
}

// linkProviderUserInfo must be a (single) UserInfo value.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

UserProvider?

Copy link
Member Author

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)) {
Copy link
Contributor

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?

Copy link
Member Author

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.)

Copy link
Contributor

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);

Copy link
Member Author

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.

/**
* The user identifier for the linked provider.
*/
uid?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

providerUid?

Copy link
Member Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/federated providers/providers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. (Also above)

});

it('can link/unlink with a federated provider', async () => {
const federatedUid = 'google_uid_' + generateRandomString(10);
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

it('should be rejected given an empty providersToDelete list', () => {
expect(() => {
auth.updateUser(uid, {
providersToDelete: [],
Copy link
Contributor

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?

Copy link
Member Author

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.)

});
});

it('specifying both phoneNumber=null and providersToDelete=phone should be rejected', () => {
Copy link
Contributor

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?

Copy link
Member Author

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.

@nrsim nrsim assigned rsgowman and unassigned nrsim Jan 24, 2020
@rsgowman rsgowman force-pushed the rsgowman/link_by_federated_id branch from caac5bc to c79f42d Compare January 28, 2020 15:53
@rsgowman rsgowman assigned nrsim and unassigned rsgowman Jan 28, 2020
@@ -961,6 +968,31 @@ export abstract class AbstractAuthRequestHandler {
'Properties argument must be a non-null object.',
),
);
} else if (validator.isNonNullObject(properties.providerToLink)) {
Copy link
Contributor

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.

Copy link
Member Author

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.

@google-cla
Copy link

google-cla bot commented Dec 22, 2020

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.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@rsgowman rsgowman assigned hiranya911 and unassigned nrsim Dec 22, 2020
@hiranya911
Copy link
Contributor

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 npm run api-extractor:local and commit the changes.

@hiranya911 hiranya911 assigned rsgowman and unassigned hiranya911 Jan 7, 2021
@google-cla
Copy link

google-cla bot commented Feb 4, 2021

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.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

@rsgowman rsgowman force-pushed the rsgowman/link_by_federated_id branch from 7f077e8 to a3f8f69 Compare February 4, 2021 18:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants