[Pulp-dev] AccessPolicy Model Advice ... input needed

[Brian Bouterse]

On Tue, Jul 14, 2020 at 4:37 AM Matthias Dellweg <mdellweg at 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 <dkliban at 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 <bmbouter at 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 at redhat.com
> >> https://www.redhat.com/mailman/listinfo/pulp-dev
> >
> > _______________________________________________
> > Pulp-dev mailing list
> > Pulp-dev at redhat.com
> > https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200714/ca97d0c6/attachment.htm>