Announces django-guardian: per object permissions for Django 1.2
lukaszb
I'd like to announce django-guardian - very basic yet usable per
object permissions
implementation for Django 1.2, using new authorization backend
facilities.
It was created during 2 days sprint, code have been released and may
be found at http://github.com/lukaszb/django-guardian/.
Documentation is available at http://packages.python.org/django-guardian/.
Currently I think there should be better integration with admin app
and some shortcuts (permission assignment/removal)
should support table-level permissions as well.
If you spot a bug or have an idea how to improve this little app,
please spare a minute at issue tracker, which is located at
http://github.com/lukaszb/django-guardian/issues.
Hope someone would find this useful.
Take care,
Lukasz
Russell Keith-Magee
Hi Lukasz,
Great stuff! Thanks for taking the effort to implement this and put it
out in the open. It's a fantastic example of the sort of thing that
can be very useful without needing to be part of core, which is the
reason that we put the object-based permissions API into the auth
backends.
Regarding admin app integration -- integration of object-level
permissions with the admin app is one area where I am aware there are
some bugs (or, at least, some areas where the object-based permissions
API isn't being used as it should). This aspect of Django's admin
could do with some attention, so if your experience of implementing an
object-based permissions backend has you contemplating a bigger
project, auditing the admin for adherence to object-based permissions
could be an interesting candidate.
Yours,
Russ Magee %-)
derek
> Hi all,
>
> I'd like to announce django-guardian - very basic yet usable per
> object permissions
> implementation for Django 1.2, using new authorization backend
> facilities.
>
> It was created during 2 days sprint, code have been released and may
> be found athttp://github.com/lukaszb/django-guardian/.
> Currently I think there should be better integration with admin app
> and some shortcuts (permission assignment/removal)
> should support table-level permissions as well.
>
> If you spot a bug or have an idea how to improve this little app,
> Hope someone would find this useful.
Django admin is a must, though, as permissions will need to be
assigned by users themselves via the standard interface.
One (maybe stupid) question: Can rights only be assigned to the pre-
specified "Group", or can any model that handles user grouping (I have
some custom ones in my app) be used?
Thanks
Derek
lukaszb
Group) models for which one may define permission sets and I wanted
guardian to be as simply as possible - so it is not possible to assign
permission to other model even if it "groups users". At one point I
thought it could be nice to implement some kind of "roles" but I've
finally decided it would be better to stick to facilites provided by
new Django version.
On the other hand, I'm not sure if it is needed to create new
"grouping models" - I often use intermediate models for this (i.e.
Team model with fk to Group among other fields). Let me know if you
have different experience.
lukaszb
included" parts of Django are extremely useful (and fun to extend if
needed).
About the admin, I haven't really get into admin integration yet as I
cannot answer this: should user with "flatpages.change_flatpage"
permission for flatpage instance be able to edit it at admin if he/she
doesn't have "flatpage.change_flatpage" global permission? I'm just
stuck here - I suppose it would be good to "turn off" ability to
change some objects for user with this global "app.change_obj"
permission removal. On the other hand, wouldn't it be too much to give
such global permission for user if we intend to allow him/her to
change only single object?
Am not sure if I should start such discussion here but I just couldn't
resist :)
On 4 Sie, 01:34, Russell Keith-Magee <russ...@keith-magee.com> wrote:
> > Hi all,
>
> > I'd like to announce django-guardian - very basic yet usable per
> > object permissions
> > implementation for Django 1.2, using new authorization backend
> > facilities.
>
> > It was created during 2 days sprint, code have been released and may
> > Documentation is available athttp://packages.python.org/django-guardian/.
derek
that case.
Russell Keith-Magee
> Thanks for the comment! I really do think that this "backends ready &&
> included" parts of Django are extremely useful (and fun to extend if
> needed).
>
> About the admin, I haven't really get into admin integration yet as I
> cannot answer this: should user with "flatpages.change_flatpage"
> permission for flatpage instance be able to edit it at admin if he/she
> doesn't have "flatpage.change_flatpage" global permission? I'm just
> stuck here - I suppose it would be good to "turn off" ability to
> change some objects for user with this global "app.change_obj"
> permission removal. On the other hand, wouldn't it be too much to give
> such global permission for user if we intend to allow him/her to
> change only single object?
There are two possible readings of the global obj=None case.
a) A user must have the global permission in order to be granted the
permission for individual objects. This means that the global
permission is a 'gatekeeper' of sorts for individual object
permissions.
b) The global permission is the 'fallback' permission if a specific
object permssion doesn't exist. That is the obj=None permission is the
"allow all" permission.
My reading of the code and docs [1] [2] is that (b) is the intended
interpretation. From a practical standpoint, this also makes sense: in
the case of (a), there is no way to grant a wildcard permission.
[1] http://docs.djangoproject.com/en/dev/topics/auth/#django.contrib.auth.models.User.has_perm
[2] http://code.djangoproject.com/wiki/RowLevelPermissions
So - in terms of the practical situation you describe; this means that
a user can only edit a specific flatpage if they have the change
permission for a specific instance, *or* they have the global obj=None
permission.
The issue that cascades on from this is the UX issue of how to
represent an object that you can't edit. Should it be displayed, but
not presented as a link? Should it be hidden entirely?
Yours,
Russ Magee %-)