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

[Matthias Dellweg]

On Tue, Jul 14, 2020 at 12:24 PM Brian Bouterse <bmbouter at redhat.com> wrote:
>
>
>
> 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/
ty
>
>> 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.
That kind of answers my question, that was: Does the code have enough
contextual information to build the viewsets base_path or class_path.
And is one of them significantly easier to derive / more canonic?
Both solutions lead to equally unique keys, right?
>
>>
>> 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
>>