-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstracting permissions frameworks #1
base: bug/coral_dockerfile_for_arches_7.5
Are you sure you want to change the base?
Abstracting permissions frameworks #1
Conversation
…stgres APT support
…tently in the docker setup
9fbc6ae
to
65c9622
Compare
The more I think about this, I do feel like the only way to avoid maintaining a fork is to pull this PR apart gradually, and see what is/isn't acceptable into Arches core, with the rest moving to project repo in some suitable fashion. The core concept here is unchanged, but it now contains extensions to make Casbin useful -- for example, |
Screencast.from.2023-09-23.22-57-41.webm
This is an example for discussion, so is not yet polished
Following up on ideas and challenges that have come up for us, where the established permissions approach is not optimal for our use-cases, this issue aims to open dialogue on how permissions rules could be more internally abstracted.
What is being suggested?
Centralizing (and abstracting) any
django-guardian
calls such that alternative RBAC logic can be swapped in, in a similar way to how storage backends, search components, datatypes, etc. can be currently.Why is this necessary?
At present, users or groups are red-listed rather than green-listed by default, which works well when most data is open, but for instances with substantial amounts of non-public data, it can slow indexing for large numbers of users and falls back to allow if any coding/role-assignment issues occur. Moreover, in these cases, some of the (cascading sequences of) checks make group logic less intuitive, and require hooking extra logic on save to get, for instance, per-group visibility of resources.
Screencast shows adding a resource that is visible in search both to the logged-in admin who creates it, and to a public user (Private Browsing). The permissions framework is switched to default-deny in
settings.py
and the server restarted. The Private Browsing window no longer shows any results. (Note, however, that the count does not reflect the filtering - this may be a general issue)