[WIP] Per-object permision #658
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Create a mixin class to check permission logic: - For Service/Farm, the object being checked is itself. - For Project, the object being checked is itself or its parent Service. - For Host, the object being checked is its parent Farm. - For Exporter/URL, the object being checked is its parent Project or the Service that is the parent of the Project. - For Rule/Sender, the object being checked is its parent Service/Project. - Other cases only have permission if the user being checked is a superuser. Apply the mixin class to Django's View classes: - The 'ServiceRegister' class is not applied, therefore any user can create a new service. - 'View' classes the user to have Viewer, Editor or Admin roles. - 'Update' classes require the user to have Editor or Admin roles. - 'Delete' classes require the user to have Admin role.
The "Default" group is the current authorization model of Promgen. It is no longer necessary after releasing the new authorization model. Therefore, the "Default" group and any related parts need to be removed from Promgen's source code.
With the new authorization model, the default permission class of Django REST Framework, DjangoModelPermissionsOrAnonReadOnly, will no longer be suitable. Therefore, we have replaced it with a new custom class. To keep things simple, the new class will require user authentication on every API and will only allow normal users to use the GET, HEAD, and OPTIONS methods. Filtering data based on user permissions will be specifically handled at each API.
We add a filter to the HomeListView to show only the Services that the currently logged-in user has permission to access.
We add a filter to the ServiceListView to show only the Services that the currently logged-in user has permission to access.
We add a filter to the RulesListView to show only the Rules of the Services or the Projects that the currently logged-in user has permission to access.
We add a filter to the FarmListView to show only the Farms that the currently logged-in user has permission to access.
We add a filter to the URLListView to show only the URLs of the Projects that the currently logged-in user has permission to access.
We add a filters the HostListView to show only the Hosts of the Farms that the currently logged-in user has permission to access.
We add a filter to the Alert History page to show only the alerts of the Services or the Projects that the currently logged-in user has permission to access.
We add a filter to the Edit History page to show only the audit logs of the objects that the currently logged-in user has permission to access.
We add a filter to the SearchView to show only the objects of the search result that the currently logged-in user has permission to access.
We add filters to the DatasourceListView and DatasourceDetailView to show only the projects that the currently logged-in user has permission to access.
We add filters to the HostDetailView to show only the hosts and their related objects that the currently logged-in user has permission to access.
We add filters to the Proxy's APIs response to return only the alerts and the silences of the services or the projects that the currently logged-in user has permission to access.
We add a filters to the responses of the Service retrieve APIs to show only the data that the authenticated user has permission to access.
We add a filters to the responses of the Project retrieve APIs to show only the data that the authenticated user has permission to access.
We add a filters to the responses of the Farm retrieve APIs to show only the data that the authenticated user has permission to access.
We add a filters to the responses of the Export Rules API to show only the data that the authenticated user has permission to access.
We add a filters to the responses of the Export Targets API to show only the data that the authenticated user has permission to access.
We add a filters to the responses of the Export URLs API to show only the data that the authenticated user has permission to access.
We implement a permission check logic at the Prometheus proxy API to ensure that users must have the Admin or Editor role on the service/project when they want to silence an alert for that service/project.
We implement a permission check logic at the Prometheus proxy API to ensure that users must have the Admin or Editor role on the service/project when they want to delete a silence for that service/project.
We add a filters the GroupListView to show only the Groups that the currently logged-in user has permission to access.
hoangpn
force-pushed
the
feature/per_object_permision
branch
from
87e359f to
4a964f1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.