This page is meant for brainstorming & idea gathering. Currently a final solution does not exist. Once it does, this page can be replaced or removed.
- Ideally, we would not like to hardcode "roles" or permission levels into the Angular UI itself.
- Some areas of the UI currently hardcode roles, e.g. https://github.com/DSpace/dspace-angular/issues/393
- Instead, we'd prefer all authorization information (for currently logged in user) be passed to the UI layer via the REST API response (or cached as needed based on previous responses, e.g. a user's group membership may need to be cached on login)
- There is no clear single solution for all scenarios/needs in the UI layer. We may need to use different solutions for different scenarios (uncertain)
- More background info here: https://github.com/DSpace/dspace-angular/issues/242
Possible Solutions / Partial Solutions
- For some areas of the UI, it may be relatively easy to describe authorization rights using predefined HAL
_links(i.e. if a link is present you can perform a specific action) in the latest REST response.
- For example, on an Collection page, the UI could display an "Edit" link only if a HAL link named "edit" is provided in the Collection's REST response. This may be an easy way for the backend to return the currently logged in user's access on a single object by just specifying which links are available to that user.
- For some areas of the UI, it may be necessary to check a user's Group membership to determine authorization rights
- For example, Administrative options (at the Site level) should only be displayed if the user is a member of the "Administrator" group.
- This group membership information may need to be cached in the UI layer, as it won't be available in every response.