Closed Bug 926673 Opened 6 years ago Closed 5 years ago

Apply authorization levels and privacy settings to API responses

Categories

(Participation Infrastructure :: Phonebook, defect)

2015-2.3
defect
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: hoosteeno, Unassigned)

References

(Blocks 2 open bugs)

Details

We currently serve all profile data to API requests coming from API users with the "Corporation" flag. We can't keep doing that because the "Corporation" flag has been distributed to non-Corporation API consumers (furthermore, the definition of a "Corporation" API consumer was never very clear). 

We should respond to (most) API requests with the same data we'd respond to UI requests with. That data payload is determined by juxtaposing the requester's authorization group with the per-field privacy settings of data requested. 

If we need an extra special authorization group that gets all data (a "superuser" group, for example) we must specify what justifies having that access and we must only allocate it to qualifying parties.

This bug relates to the authorization refactor described in bug 926644.
No longer blocks: 926644
Our thinking on this has evolved since Comment 0 was written.

When we tackle 1011209, we'll fix this bug. "Fixing" it means:

* API responses including user information must include the privacy level associated with any user data. Here is a pseudocode example of what might be returned by the /users/ resource:
[
    {
        username: {value:"hoosteeno", privacy:"public"},
        bio: {value:"Builds bugs.", privacy:"mozillians"}
    },
]

Important note: The design of the new API will limit the number of API consumers who will need to worry about the privacy level of returned fields. Bug 1011220 explains that vouched-mozillian API keys (the majority of keys given) will see only public information. Bug 1011227 explains that a small number of API keys will have elevated access. And bug 1011230 explains that these things will be publicly described in an FAQ.
Assignee: nobody → giorgos
Status: NEW → ASSIGNED
What should we do with the "Sites that can determine my vouched status" and "Allow Mozilla sites to access my profile data?" profile settings?

I suggest that we:
 * Ignore them in APIv2 since we'll apply per field privacy settings in API responses.
 * Change the wording in edit profile page to say that this is only for APIv1
 * Drop them along with APIv1
Flags: needinfo?(hoosteeno)
(In reply to Giorgos Logiotatidis [:giorgos] from comment #2)
> What should we do with the "Sites that can determine my vouched status" and
> "Allow Mozilla sites to access my profile data?" profile settings?

It's a good question, and one that I think needs some more discussion.

I suggest something different than comment 2:

* Until APIv2 is launched, these checkboxes should do exactly what they do now.
* When APIv2 is launched, we should have only one checkbox: "Hide my profile and group memberships from all API requests. Note: This will prevent you from accessing information and features on [other Mozilla sites](link to FAQ where we list them)."
Flags: needinfo?(hoosteeno)
De-assigning myself since I'm not working on mozillians now.
Assignee: giorgos → nobody
Status: ASSIGNED → NEW
Merged here: https://github.com/mozilla/mozillians/pull/1152
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Version: other → next
Commits pushed to master at https://github.com/mozilla/mozillians

https://github.com/mozilla/mozillians/commit/f1955099f67f8a7fd78e2b6f1d253a55317b72de
[Fix bug 926673] Use privacy aware attributes instead of queries.

* Add WEBSITE external account field.

https://github.com/mozilla/mozillians/commit/9cbf1b3fce78f1437b66975b10eb5353317266c6
Merge pull request #1171 from johngian/fix-permissions

[Fix bug 926673] Use privacy aware attributes instead of queries.
Verified on stage:

* Users endpoint
** Tested that all fields are available only when api key privacy level is higher or equal to the one that the user requires
** Repeated the same procedure for all different permission levels (public, mozillians, privileged)
* Groups, skills
** Tested that only approved members are returned in the group's users
** Tested that permission check works as expected (only users that should be available in the results are returned as members)
Status: RESOLVED → VERIFIED
Version: next → 2015-2.3
You need to log in before you can comment on or make changes to this bug.