We probably don't want to decide UI access based on user's potential actions on that UI module. Why?
One UI module might involves many actions and we want to max. reuse the UI so that:
some users might not have access to certain action but still be able to access the UI module
e.g. "View Users Page". Even a user without update user permission should be able to access this UI module as long as the user can view some users.
Cost is high (as we need to consult auth decision for all possible actions)
Inaccurate & "too early to tell"
Some auth decision is related to the data supply and can only be determined at the time when the action is performed
e.g. update a user
Hard to reflect the user's true intention.
it's possible that we want to hide some UI module event the users have the permission to perform the required (or partial) actions
Alternative Approach / Solution
Managing access to UI module by accessing URL path
Allow system to manage the new access items: UI module. It comes with the following attributes:
id
name
URL path
description
landingWeight
an optional number indicate which module should be the default landing module for the current user.
the module with highest landingWeight among all modules that the user can access will be the landing module for the user.
ownerId
createTime
creatorId
editTime
editorId
pre-authorised-permissionIds: this list should be managed by a separate table ui_module_permissions with the following field
permission id
module id
createTime
creatorId
editTime
editorId
We need the following APIs
POST /content/ui/modules create a new UI module
GET /content/ui/modules list all accessible UI modules.
This API will always restrict the access to pre-authorised modules even you have ui/module/read with no constraint
why? e.g. Admin users can every modules. but for purpose of menu items generation, we will only want to retrieve the items that specifically assigned to him.
GET /content/ui/modules/all list all UI modules that users can access
PUT /content/ui/modules/{id} update an UI module
DELETE /content/ui/modules/{id} delete an UI module. You can't delete an UI module when there is still records attached to it.
POST /content/ui/modules/{id}/role/{roleId} Assign a UI module to a role
A ad-hoc auto-permission will be created with operation url: ui/module/read & pre-authorised constraint
a relevant record will be added to the ui_module_permissions table
The created permission will be assigned to the selected role
DELETE /content/ui/modules/{id}/role/{roleId} Remove a UI module from a role
a list all permissions of the role with uri: "ui/module/read" & pre-authorised constraint
Any permission with matching ui module id can be found from ui_module_permissions will be deleted from ui_module_permissions
the permission record will be deleted as well
upon login, the UI should request GET /content/ui/modules endpoint to retrieve a list of permitted modules
How to determine the default landing URI for a user?
Each UI module record comes with a landingWeight with default value 0
System will pick the item with highest value of this field as the default landing URL / UI module
Better UI Access Control Mechanism
We probably don't want to decide UI access based on user's potential actions on that UI module. Why?
update a user
Alternative Approach / Solution
landingWeight
among all modules that the user can access will be the landing module for the user.ui_module_permissions
with the following fieldPOST /content/ui/modules
create a new UI moduleGET /content/ui/modules
list all accessible UI modules.ui/module/read
with no constraintGET /content/ui/modules/all
list all UI modules that users can accessPUT /content/ui/modules/{id}
update an UI moduleDELETE /content/ui/modules/{id}
delete an UI module. You can't delete an UI module when there is still records attached to it.POST /content/ui/modules/{id}/role/{roleId}
Assign a UI module to a roleui/module/read
& pre-authorised constraintui_module_permissions
tableDELETE /content/ui/modules/{id}/role/{roleId}
Remove a UI module from a roleui_module_permissions
will be deleted fromui_module_permissions
GET /content/ui/modules
endpoint to retrieve a list of permitted moduleslandingWeight
with default value 0