Modeling Permission

Three shapes, and most applications need two of them.

Ownership. Is this yours? Depends on the specific record, so it cannot be answered by a role.

Role. Are you staff, an editor, an admin? Answered once per person, not per record.

Relationship. Are you a member of the team this belongs to? The common one people model badly, usually by adding a role that means 'member of team 7'.

Answer ownership in the query. Fetching with the owner as part of the lookup means the wrong record cannot be retrieved at all. There is no separate check to forget, and a missing record fails as a 404 rather than a 403, which also avoids confirming that somebody else's record exists.

Answer roles with the permission system your framework already has. Answer relationships with a real table, because that is what they are.

◈ Graded Challenge

Write can(action, user, doc) deciding permission from all three shapes. doc has owner, team and visibility, where visibility is "public", "team" or "private". user is None for a signed-out visitor, or a dictionary with name, teams (a list) and is_staff. Rules: "view" is allowed for a public doc by anyone; for a team doc by the owner, staff, or a member of that team; for a private doc only by the owner or staff. "edit" and "delete" are allowed only for the owner or staff, whatever the visibility. A signed-out visitor may only view public docs.

Name it exactly: can(action, user, doc)

Python4 visible + 5 hidden
loading editor…

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: Practice Test →
← Back