Add view and control to default permissions, if possible
Right now we need to define view and control permission in the meta class of every model so that they can be used and served by Django LDP.
Django LDP should add them to the default permissions of every model. The problem is that they are hard coded in django. The only solution seems to be a runtime patch.
Activity
The design consideration here is whether we ought to be able to use existing models in LDP without modifying them.
The Urls mapping acts as a default registry (another way of doing this would perhaps be in settings - and inject the url mappings automatically
By Rob on 2018-10-24T10:10:12 (imported from GitLab project)
mentioned in issue #52 (closed)
Is this actually a duplicate of #50 (closed)?
By Rob on 2018-11-04T20:42:39 (imported from GitLab project)
mentioned in issue #50 (closed)
By Rob on 2018-11-05T12:05:26 (imported from GitLab project)
(moved from #50 (closed)) Just checking the requirement here:
in this case..
class LDNotification(models.Model): user = models.ForeignKey(settings.AUTH_USER_MODEL) author = models.URLField() object = models.URLField() type = models.CharField(max_length=255) summary = models.TextField() class Meta: permissions = ( ('view_todo', 'Read'), ('control_todo', 'Control'), )there is some binding (the one in urls.py?) of the token "todo" (i cant see any other mention in djangoldp) to the class LDnotification, so that these permissions are checked? And this is ugly because the class cant and really shouldnt know what it gets bound to, hence we want to inject these automatically on binding?
By Rob on 2018-11-05T12:06:29 (imported from GitLab project)
I'm not sure of what kind of binding you have in mind.
The permissions are checked here: https://git.happy-dev.fr/startinblox/djangoldp/blob/master/djangoldp/views.py#L37
and here: https://git.happy-dev.fr/startinblox/djangoldp/blob/master/djangoldp/views.py#L53
-
The default permissions are set here: https://github.com/django/django/blob/master/django/db/models/options.py#L96
In 1.11 view is not included in that list.
Maybe we can override this method.
specifically - in the example above how does the token "todo" get applied to the model LDNotification so that the line
perm="view_{}".format(queryset.model._meta.model_name.lower())picks up the right permission.
It is at this point that it would become possible to set these permissions.
(I can hunt this down but i hoped i could get a quick answer)
By Rob on 2018-11-06T20:01:54 (imported from GitLab project)
-
Oh I think I get it... You're refering to the "todo" of this line? https://git.happy-dev.fr/startinblox/djangoldp/blob/master/djangoldp/models.py#L28
If that's the case, it's a mistake. There shouldn't be any "todo" anywhere. That's actually the reason why we need to get rid of these lines ;)
OK - I'm thinking that the "registration" process is, by default this: url(r'^members/', LDPViewSet.urls(model=Member, nested_fields=("skills",))),
so could we set default permissions at the same time as we create the ViewSet - and have an optional parameter to override these defaults...
url(r'^members/', LDPViewSet.urls(model=Member, permissions=Something, nested_fields=("skills",))),
Q1 - does it already take some sort of permissions override - quick scout of docs and google didnt find anything Q2 - what does Something look like.. one choice is.. ( ('view_source', 'acl:Read'), ('control_source', 'acl:Control'), )
but it seems redundant - we know the model - and where are the keyword "view_" and "Read" (and what does acl:Read mean vs Read) defined. I have browsed code rest and guardian documentation and havent yet located references for this - so quickest if you can provide a pointer.
Q3 - do we only want absolute overwrite of defaults, or optional extra_permissions=() and exclude_permissions=() params
By Rob on 2018-11-07T10:01:47 (imported from GitLab project)
-
I have checked and adding a permission does trigger a migration. I'm not sure if it actually changes something in the database, but I think it'd be better if the options set in the migrations include view and control.
Regarding the options, we have quite a few use cases, and I think we'll need some time to have a global view on them. One use case we're already having is the inbox case. Every user has a container on which any one can post a notification. So this container is publicly write only, and readable by its owner only. The way to implement this right now is to develop a Permission class in DRF. It could be interesting to have another way to do it.
-
Oh and the acl:Read thing comes from here https://github.com/solid/web-access-control-spec
But you don't really have to bother with that. We'll deal with it with the context. I have to check, but we probably want to replace them with Read in Django.
