ACL

231 views
Skip to first unread message

Jeff Anderson

unread,
Jan 7, 2009, 2:57:10 PM1/7/09
to django-d...@googlegroups.com
One of the most requested features/howtos/how-comes/why-nots that show
up on the Django users list is Access Control Lists, or row-level
permissions. Almost always, the question is about how to get the admin
app to use them. This is outside of the scope of the admin app, and
that's usually the answer that is given.

Would including a built-in contrib app that implements access control
lists be outside the scope of Django?

I figure a design similar to the current admin site will be needed to
create a generic ACL subsystem. An access list would be defined for each
app, similar to how an admin site is defined in admin.py. I'm willing to
spend some time on this, but I'd like any opinions as to the best way to
implement it before I spend more than a weekend or two on this idea.

I don't think that there is a Django ACL implementation quite like I
have in mind. Most ACL functionality I imagine is written in views that
go with a specific app. A standard implementation of ACL in contrib one
would allow for more pluggable pluggable apps.

Let me know what you think!

Thanks!


Jeff Anderson

signature.asc

mattim...@gmail.com

unread,
Jan 7, 2009, 5:06:54 PM1/7/09
to Django developers
Django Granular Permissions is quite flexible and its usage does not
depend on the admin or any other app. It uses Generic Relations and
can be added to models in the Django admin with Generic Inlines.

[1] http://code.google.com/p/django-granular-permissions/

cheers

Matthew

--
Matthew Flanagan
http://wadofstuff.blogspot.com

Malcolm Tredinnick

unread,
Jan 7, 2009, 8:14:55 PM1/7/09
to django-d...@googlegroups.com
On Wed, 2009-01-07 at 12:57 -0700, Jeff Anderson wrote:
> One of the most requested features/howtos/how-comes/why-nots that show
> up on the Django users list is Access Control Lists, or row-level
> permissions. Almost always, the question is about how to get the admin
> app to use them. This is outside of the scope of the admin app, and
> that's usually the answer that is given.
>
> Would including a built-in contrib app that implements access control
> lists be outside the scope of Django?

It may not be. However, this isn't really the right question to ask. The
right question is "why has nobody built the kick-ass implementation that
everybody needing this is prepared to walk across hot coals to use
because it's so wonderful?" Something like this doesn't need to be in
Django. Maybe not ever, but certainly not initially. Django is designed
so that external applications are easy to develop and don't need core
modifications. If it's built and isn't included in Django, nobody is any
worse off, because it still exists.

For good reason, we try very hard not to give advance commitment to
acceptance of anything before it exists externally. There have
historically been some very rare exceptions, but are just that:
exceptions.

If, in the process of developing said application, problems appear that
justify generalisations of abstractions being made to core, discussions
appear here and things happen. That has happened in the past and will
happen again in the future. In this case, for example, it might turn out
that some kind of subclass overriding isn't possible in the admin and
making something finer-grained to allow extensions might not be a bad
idea.

I'm also thinking that requiring evidence of people walking across hot
coals in order to use an application is probably a good pre-requisite
for inclusion in django.contrib.

Regards,
Malcolm

Graham King

unread,
Jan 7, 2009, 10:09:12 PM1/7/09
to django-d...@googlegroups.com
2009/1/7 Malcolm Tredinnick <mal...@pointy-stick.com>:

>
> I'm also thinking that requiring evidence of people walking across hot
> coals in order to use an application is probably a good pre-requisite
> for inclusion in django.contrib.
>

+1
The gmail ads are conveniently offering me 'Firewalk Teacher Training'
and 'Find a Fire-Walk near you', so this shouldn't be too hard to
organise :-)

tie

unread,
Jan 8, 2009, 5:25:24 AM1/8/09
to django-d...@googlegroups.com
About a year ago I started writing something to solve this problem, but
never got past version 0.001 alpha:
http://code.google.com/p/dumps/

The basic idea is to create a new PermissionedModel class, that can be
used just as the standard Model. The PermissionedModel automatically
checks if the current user has permissions to do some operation (View,
Create, Update, Delete, or possibly some custom operation). Permissions
are defined using a quite lax syntax, which should allow for row-based,
column-based, or any filter-based permissions.

If there anyone wants to help get this project going again, or willing
to test it in some semi-production environment, let me know :)

Regards,
tie

Reply all
Reply to author
Forward
0 new messages