In 7.x and 8.x, user permissions are obtained one-by-one in several calls to the /server/api/authz/authorizations/search/object endpoint. These requests are most easily seen after login, as you'll see ~10 of these requests in a row for the Site object:
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=isCollectionAdmin&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=isCommunityAdmin&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=administratorOf&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canSubmit&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canEditItem&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canSeeQA&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=coarNotifyEnabled&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canManageGroups&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canSendFeedback&embed=feature
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]&feature=canViewUsageStatistics&embed=feature
These requests are all identical except for the feature= parameter, where they request permissions specific to that feature.
In the REST API, we already have a way to request permissions in bulk, by just removing the optional feature parameter:
# This will return all permissions the current authenticated user has on the Site object.
GET /server/api/authz/authorizations/search/object?uri=https://sandbox.dspace.org/server/api/core/sites/[site-uuid]
Ideally, we should avoid one-by-one requests of this sort, and request all the authorizations at once and cache them for the remainder of the user's session. If additional endpoints or options are necessary in the REST API, then we should add them to better support this request for bulk permissions.
To Reproduce
Steps to reproduce the behavior:
Visit demo.dspace.org or sandbox.dspace.org
Open Chrome DevTools
Login as an Admin, and look at the number of requests made to the /server/api/authz/authorizations/search/object endpoint
Expected behavior
Ideally, we should request user permissions in one request (or fewer requests) and cache them for the remainder of the user's session.
Describe the bug
In 7.x and 8.x, user permissions are obtained one-by-one in several calls to the
/server/api/authz/authorizations/search/object
endpoint. These requests are most easily seen after login, as you'll see ~10 of these requests in a row for theSite
object:These requests are all identical except for the
feature=
parameter, where they request permissions specific to that feature.In the REST API, we already have a way to request permissions in bulk, by just removing the optional
feature
parameter:Ideally, we should avoid one-by-one requests of this sort, and request all the authorizations at once and cache them for the remainder of the user's session. If additional endpoints or options are necessary in the REST API, then we should add them to better support this request for bulk permissions.
To Reproduce
Steps to reproduce the behavior:
/server/api/authz/authorizations/search/object
endpointExpected behavior
Ideally, we should request user permissions in one request (or fewer requests) and cache them for the remainder of the user's session.