On Tue, Jul 14, 2020 at 4:37 AM Matthias Dellweg <mdell...@redhat.com> wrote:
> I think, it would help me to understand if you could reiterate what > kind of policy this model holds. Is it the class level permission like > "Only admins can create new repositories."? > It holds a database equivalent of this policy for example: https://github.com/pulp/pulp_file/compare/master...bmbouter:rbac-PoC#diff-b8a33258feb0183716da827efd0b4102R19-R54 These would be loaded 100% from the DB and no longer in code. This is more or less recommended by drf-access-policy here https://rsinger86.github.io/drf-access-policy/loading_external_source/ What kind of context does a lookup for these objects? Is it the > PermissionClass that carries a context containing an instance to the > view / viewset, or the request with the resolver_match? > It only holds the policy, the context data is available on the request and in the task, so only the "statements" live in the db. > If it is userfacing i would probably also go for option 1 with the hrefs. > > On Tue, Jul 14, 2020 at 2:21 AM Dennis Kliban <dkli...@redhat.com> wrote: > > > > Pulp 2 users would definitely be familiar with describing policies in > terms of urls. The Pulp 3 REST API already uses the pulp_href field as the > primary identifier. You should implement idea 1. > > > > On Mon, Jul 13, 2020, 5:45 PM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> > >> I need some design input. To store AccessPolicy data in the DB I think > we want one Model where each instance is the access policy for a given > viewset. I think this would be better than one Model per Viewset which > would generate N tables for N viewsets with 1 instance of each which would > be very strange and inefficient. > >> > >> So let's assume we have a simple definition like the one below. Each > instance stores the policy for one viewset. > >> > >> class AccessPolicy(BaseModel): > >> data = JSONField() > >> > >> So what second field can I add to this that would allow me to relate an > instance of this model to a viewset. For example the FileRemoteViewset > here: > https://github.com/pulp/pulp_file/blob/de638519fc02d588f403db4c5cfcca7552543c50/pulp_file/app/viewsets.py#L116 > >> > >> Idea 1: Add a viewset = CharField(). Have it store values as URLs, e.g. > /pulp/api/v3/remotes/file/file/. > >> Idea 2: Add a viewset = CharField(), and have it store values as > classpaths, e.g. 'pulp_file.app.viewsets.RemoteFileViewset'. > >> > >> I think Idea 1 makes the most sense because that's how our users think > of it. I can't think of a good alternative. What do you think makes the > most sense? What alternative ideas should we consider? > >> > >> If you have feedback please share it. I need to start into something to > get it going tomorrow even if it's just Idea 1 for lack of an alternate > proposal. > >> > >> Thanks, > >> Brian > >> _______________________________________________ > >> Pulp-dev mailing list > >> Pulp-dev@redhat.com > >> https://www.redhat.com/mailman/listinfo/pulp-dev > > > > _______________________________________________ > > Pulp-dev mailing list > > Pulp-dev@redhat.com > > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev