You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, period models can be edited by anyone able to make an HTTP request to the application backend. The application performs no authentication or authorization checks of its own, relying on a proxy server to apply such checks before requests reach it.
This makes it cumbersome to apply more sophisticated access controls, such as "group A may read and write periods for team X, while group B may only read them; group C may read and write periods for team Y".
The best solution I currently see would be to add fields like "readACL" and "readWriteACL" to the Team entity, indicating the lists of users (or groups) that can perform those actions to entities belonging to that team. Then, the application itself would need to perform authentication on all requests for those entities, checking that the requesting user is authorised before proceeding to serve the request.
To protect users from locking themselves out accidentally, an empty ACL (the default) should probably mean access is unrestricted. The UI should also probably warn the user if they are about to perform an action that would restrict their own access in some way.
The specific authentication mechanism used should be "pluggable", with the details hidden behind a Go interface, similar to the way the data storage mechanism is currently.
The ability to control access to the list of teams, and to the ability to add new teams, may also be useful.
The text was updated successfully, but these errors were encountered:
Currently, period models can be edited by anyone able to make an HTTP request to the application backend. The application performs no authentication or authorization checks of its own, relying on a proxy server to apply such checks before requests reach it.
This makes it cumbersome to apply more sophisticated access controls, such as "group A may read and write periods for team X, while group B may only read them; group C may read and write periods for team Y".
The best solution I currently see would be to add fields like "readACL" and "readWriteACL" to the Team entity, indicating the lists of users (or groups) that can perform those actions to entities belonging to that team. Then, the application itself would need to perform authentication on all requests for those entities, checking that the requesting user is authorised before proceeding to serve the request.
To protect users from locking themselves out accidentally, an empty ACL (the default) should probably mean access is unrestricted. The UI should also probably warn the user if they are about to perform an action that would restrict their own access in some way.
The specific authentication mechanism used should be "pluggable", with the details hidden behind a Go interface, similar to the way the data storage mechanism is currently.
The ability to control access to the list of teams, and to the ability to add new teams, may also be useful.
The text was updated successfully, but these errors were encountered: