-
Notifications
You must be signed in to change notification settings - Fork 40
fix(scopes): Formalize and document scope-handling rules. #551
Conversation
docs/scopes.md
Outdated
|
||
* Be an absolute `https://` URL. | ||
* Have no query component. | ||
* Have a fragment component consisting only of alphanumeric ascii characters. |
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.
Random drive-by comment, but this wording makes it sound like the fragment part is mandatory because of the MUST before the list. Maybe clarify here with an "if specified..." clause, or split out to a separate MAY list?
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 include MUST / MAY in each bullet rather than aggregated at the top)
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.
Thanks, good call, I will update.
docs/scopes.md
Outdated
introduced during earily development. | ||
|
||
**No new short-name scope values should be added.** | ||
Instead we prefer to use URLs for new scope 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.
+No new short-name scope values should be added.
Instead we prefer to use URLs for new scope values,
Ah interesting 👍 . I'm surprised to hear this but i guess this makes sense after looking at Google's list of these scopes
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.
We can always revisit this as time goes on, if we find the URL syntax to be unwieldy.
* `https://identity.mozilla.com/apps/oldsync#read` indicates | ||
read-only access to the user's data in Firefox Sync. | ||
* `https://identity.mozilla.com/apps/oldsync/history#write` indicates | ||
write-only access to the user's history data in Firefox Sync. |
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.
yeah!!
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.
r+, @rfk let's add the link to the fxa-shared implementation that we have in this doc as well (once that lands). I think that should be useful for future readers
Thanks @vladikoff; I think I'll leave this open until I have a corresponding PR to use it in some of our other codebases, in case that reveals some opportunities for API cleanup. |
@rfk - is there anything else you want to add to this? |
Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:
Guidelines are available at https://github.com/mozilla/fxa-oauth-server This message was auto-generated by https://gitcop.com |
Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:
Guidelines are available at https://github.com/mozilla/fxa-oauth-server This message was auto-generated by https://gitcop.com |
Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:
Guidelines are available at https://github.com/mozilla/fxa-oauth-server This message was auto-generated by https://gitcop.com |
Thanks for contributing! Unfortunately, I'm here to tell you there were the following style issues with your Pull Request:
Guidelines are available at https://github.com/mozilla/fxa-oauth-server This message was auto-generated by https://gitcop.com |
@rfk - what's left to do here? |
I made a combined tracking issue to summarize status: #575 |
c01f8f5
to
83f8875
Compare
This'll need re-review given the evolution of the shared checking code.
8713663
to
6c5a8e4
Compare
This has been updated to use a tag of fxa-shared rather than a github ref; @mozilla/fxa-devs r? |
* `profile:write` implies `profile:email:write`. | ||
* `profile:email:write` implies `profile:email`. | ||
* `profile profile:email:write` implies `profile:email`. | ||
* `profile profile:email:write` implies `profile:display_name`. |
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.
Did you mean profile profile:display_name:write
implies profile:display_name
?
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.
Did you mean profile profile:display_name:write implies profile:display_name?
profile
implies profile:display_name
(both read-only), the profile:email:write
is needed to write to the email.
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.
@rfk This looks good and makes sense to me. However, I wouldn't mind extra eyes on this since I am not very familiar with the repo.
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.
Only a couple comments about the docs, logic looks good to me.
* `profile:locale`: access the user's locale. | ||
* `profile:avatar`: access the user's avatar picture. | ||
* `profile:display_name`: access the user's human-readable display name. | ||
* `profile:amr`: access information about the user's authentication methods and 2FA status. |
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 there be any indication on whether any of these are read vs read/write? uid/locale/amr I imagine are read-only.
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 true that the amr
cannot be modified, but "profile:amr:write" is still a well-formed scope with well-defined semantics (that doesn't happen to grant you any addition powers over "profile:amr".
but not to other data types. | ||
* `https://identity.mozilla.com/apps/oldsync#read` indicates | ||
read-only access to the user's data in Firefox Sync. | ||
* `https://identity.mozilla.com/apps/oldsync/history#write` indicates |
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.
Why would one want write-only access to history?
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.
If you're a mobile app that wants to record visits that can show up in the activity-stream on the user's desktop, but we don't want to let you read the sites that the user has been visiting on other devices.
docs/scopes.md
Outdated
|
||
We say that a scope value A *implies* another scope value B | ||
if they are exactly equal, | ||
of if A represents a more general capability than B. |
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.
of if
=> or if
* `profile:write` implies `profile:email:write`. | ||
* `profile:email:write` implies `profile:email`. | ||
* `profile profile:email:write` implies `profile:email`. | ||
* `profile profile:email:write` implies `profile:display_name`. |
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.
Did you mean profile profile:display_name:write implies profile:display_name?
profile
implies profile:display_name
(both read-only), the profile:email:write
is needed to write to the email.
docs/scopes.md
Outdated
* `profile profile:email:write` does *not* imply `profile:write`. | ||
* `https` does *not* imply `https://identity.mozilla.com/apps/oldsync`. | ||
* `https://identity.mozilla.com/apps/oldsync` does *not* imply `profile`. | ||
* `https://identity.mozilla.com/apps/oldsync#read` does *not* imply `https://identity.mozila.com/apps/oldsync/bookmarks`. |
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.
In the URL after "does not imply" do you want "mozila" or "mozilla"? Applies to this and the following 6 lines.
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 be mozilla
yeap :)
6c5a8e4
to
d7ea1fc
Compare
Thanks @vbudhram @shane-tomlinson, nits fixed. |
Connects to #575
While working on adding OAuth support for sync, I figured we should have a canonical reference for what sorts of scope we support and how we check for matches. So I started something, and here's the rendered view:
https://github.com/mozilla/fxa-oauth-server/blob/scopes-documentation/docs/scopes.md
I want to add some explicit testcases for this in the code here, but am putting the doc up for early feedback. @vladikoff does this seem sane? I think it differs slightly from the proposal in the original scoped-keys doc, in that it uses the URL fragment for qualifications like "readonly". But I quite like the ability to check scopes by parsing them as URL resource references.