search

holgi / fastapi-permissions

row level security for FastAPI framework
Other
475 stars 47 forks source link

Use polymorphic principals #10

Open eddsalkield opened 3 years ago

eddsalkield commented 3 years ago

Implements polymorphic principals using dataclasses instead of colon-delimited strings, resolving #6. This offers the advantage of more clear semantic separation between the method and value of a principal, whilst still permitting the user to define their own principals.

The implementation is mostly backwards-compatible, except where outlined. A version number bump will be required on the subsequent release if this PR is merged.

Introduces a new Principal base class, from which the new default principals of UserPrincipal, RolePrincipal, and ActionPrincipal are defined. These denote the semantics of "is the user x", "has the role x", and "can do action x" respectively.

Slightly changes the behaviour of list_permissions: instead of having a reserved magic string (permissions:*) to denote the default value in the returned dict, it instead returns a PermissionSet. The PermissionSet is a subclass of dict, which exposes a default attribute to specify what the default permission is, for the given user and resource. Any logic that previously depended on the permissions:* string will need to be rewritten to check the value of the default attribute instead, making this a (slightly) breaking change.

Since the principals are no longer strings, the example app's show_items route (/items/) will return json objects containing the "method" and "value" fields for permissionsslightly, instead of the previous string representation. This is due to pydantic's clever handling of dataclasses. Note in particular that the permissions:* magic string will not be returned, and so additional logic would need to be implemented for anyone who depends upon this string being returned.

Also adds some additional tests for the subtle case in which a "deny all" entry in the ACL precedes an "allow all".

eddsalkield commented 3 years ago

It seems like this failed to build because the patch depends upon Python 3.8's "/" as a positional-only parameter feature from PEP 457. Perhaps we can bump the Python build version in the repo to 3.8?