On 7/14/06, Chris Long <[EMAIL PROTECTED]> wrote:
>
> How would you handle multiple checkers? I'm designing RLP to work on
> top of model level checking. Would it be:
I actually hadn't thought of that. I thought there would be one and
only one type of checking for each model. I can't think of a use case
for multiple checkers, but then again it's Friday and my brain is a
little fried :)
> One thing that will need to be done if it is decided to go this way,
> is that RLP needs a relation to be generated in the ModelBase __new__
> method, it would have to changedfrom what I currently have.
>
> I think we need to have a conversation about this (on the mailing list
> or IRC channel, to get more input). I'm at the point now where I need
> to work on integrating checking of row level permissions and into the
> admin interface. I'd prefer making any changes to have our two systems
> work together now rather then redoing it after I've integrated it.
I think this part could be pretty simple. I'm planning on changing all
the permission checks in the admin system from (for example)
if not request.user.has_perm(app_label + '.' +
opts.get_change_permission()):
raise PermissionDenied
to something like:
from django.contrib.auth import has_permission
permission_name = app_label + '.' + opts.get_change_permission()
if not has_permission(request.user, permission_name, obj):
# feel free to exclude obj arg for add perms, obj doesn't make
sense in that case
raise PermissionDenied
I think if you wrote a has_permission function that only dealt with
model level and row level permissions, and then changed the admin
system to use it, integration later on with the generic auth stuff
would be almost trivial (at least as far as actual permission checks
are concerned.)
You could exclude the obj argument for things like add permissions
where obj really doesn't make sense. This will only work for checking
individual objects however. For the change lists, a custom manager is
a better option than checking permissions on each individual object
after it has been returned. You would have to explicity pass the user
or the user's id into that manager method though. There won't be any
kind of implicit security, which is really how django works now anyhow
and is fine with me.
Hmm... (random thought here) what if managers all grew a resrtict
method that took a user object and a permission? (The admin system
would only need to worry about 'change', but arbitrary permissions
should be possible) Row level resrictions on QuerySets could be
localized there. Later on other types of restrictions could be added
via registration (similar to the generic has_permission function I'm
working on.)
Joseph
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
