Skip to content
This repository has been archived by the owner on Jun 8, 2021. It is now read-only.

Add fxa:<email> to principals if profile is in requested scope? #47

Open
leplatrem opened this issue Mar 13, 2017 · 8 comments
Open

Add fxa:<email> to principals if profile is in requested scope? #47

leplatrem opened this issue Mar 13, 2017 · 8 comments
Labels

Comments

@leplatrem
Copy link
Contributor

Follow up of @magopian question: how do I know the user id of a FxA user?

Currently, we only add fxa:<user id> which is the md5 of the email or something like that., but should be considered opaque IMO.

Adding fxa:<email> would allow Kinto permissions to be defined easily for example.

Note: With kinto-portier it is a lot easier. It is always the email.

@Natim
Copy link
Member

Natim commented Mar 13, 2017

Unlike portier, you cannot access the email address for privacy reason in FxA unless you ask for the profile["email"] scope

@leplatrem
Copy link
Contributor Author

Yes but profile is our default requested scope

@Natim
Copy link
Member

Natim commented Mar 13, 2017

Not in production. And we don't actually need it for Kinto, so we shouldn't enforce it.

@leplatrem
Copy link
Contributor Author

Thanks! Closing ;)

@rfk
Copy link

rfk commented Mar 13, 2017

Currently, we only add fxa: which is the md5 of the email
or something like that., but should be considered opaque IMO.

FTR, the fxa userid is a randomly-generated opaque identifier, and you can expect it to remain stable even when we eventually ship the ability to change the email on your firefox account.

@Natim
Copy link
Member

Natim commented Mar 17, 2017

Actually, we could also make the fxa-email mandatory for some use cases where we want to enable sharing with email. It would make sense.

@Natim Natim reopened this Mar 17, 2017
@Natim
Copy link
Member

Natim commented Mar 17, 2017

In that case we could provide both principals fxa:fxaID and fxa:email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants