API: Implements role-based authorization of resource requests based on abilities consistent with the UI
The initial implementation of the resources API (paths under /api/resources
) was restricted to members of the superusers group because it did not implement role-based access control. This MR changes that for all but one of the API endpoints. The exception, GET /api/resources/by_role
, is still restricted, albeit now to the Curators policy group (not the Curator role), because the query does not currently have a performant way to filter resources according to permissions. This could change in the future, if such a way becomes available, or if it is decided to use a non-performant means of determining appropriate access.
A note for the record: The POST /api/resources
endpoint initially supported creating a resource with a given ID. Since this really should be a PUT
operation, I have decided it was a mistake and have removed that option. Technically, this is a backward-incompatible change, but as far as I am aware, this function is not yet in use; in any case the resources API is only available to authenticated users of the admin app, so no one outside of the staff would be affected.