-
-
Notifications
You must be signed in to change notification settings - Fork 26
2024 02 01 permissions
This is how JWT authentication works normally
- Enter user and password in a form, which the frontend sends to the server
- Server checks the user/pass and issues a JWT token encoded with user permissions and server secret
- Frontend stores the JWT
- Frontend passes the token with each request, which the server uses to validate the request and return content based on what the user is authorized to do
We talked about object-level permissions
and eventually realized we actually needed field-level permissions
where a project admin can see more project model fields than the average user
There were 2 django permissions packages talked about during the meeting, both of which haven't been updated in years. They're also both for object-level permissions, which doesn't meet our needs. They are django-guardian
and django-rules
. The package django-permission2
is updated recently but also object-level.
We decided that we needed a custom solution. It would need to be coded in the API endpoints
We talked about permission implementation, whether it's better to have individual having permission levels or to have actual groups. Cynthia thinks it's better to have groups internally.
Now that I have thought about it for a bit I want to push for Group permissions because that is where we can fake our "levels" layer. I do this with my multi-site CMS. My group names are basically "site_name + level" and I set up all groups (and their permissions) when I create a new site. I recently blogged about this. Ignore the first part of this and have a look starting at the code example you can find by searching for "default_model_permissions". https://cynthiakiser.com/blog/2023/11/09/site-creator.html
To do the "only look at the permissions that apply to this project" (aka make these model-level permissions into row-level permissions), we could have a filter on our endpoints that restricts the permission check to the permissions applying to that project: https://cynthiakiser.com/blog/2024/01/05/snippet-CRUD.html#permissions
For documenting permission requirements, we decided that the current way of specifying CRUD permissions per-field is fine.
Click Pages above to see all documentation in alphabetic order. The below list organizes the documentation and excludes some less critical documentation.
Onboarding
- Onboarding & offboarding all non-Product team members☑️
- Onboarding & offboarding Product team members☑️
- Additional technical onboarding for Developers☑️
Guides
Draft
- How-Knowledgebase-will-use-People-Depot
- Auto generating seed data scripts from data - generic, non-people depot specific
- Requirements for People Depot V1☑️
- People Depot Tables and Fields☑️
- Other related data☑️
- Stakeholder's that will use People Depot☑️
Security Requirements, Test Cases, and Technical Design
- Security: Functional Requirements. Derived from Test Cases in Issue #150
- [Test Cases] - pending, see Test Cases in Issue #150
- Security: Field Level Proposal (using Github Copilot