New Permissions Scheme

[Ramez Ashraf]

Good day dear fellow Django developers,

Current permissions scheme in Django does suffer many flaws
Like Inconsistency with permissions for proxy models #11154 and the fact that permission names are not translatable (no translation in the database) and the Permission Widget (FilteredSelect) is not very user friendly if we have a lot of models.
Some of these issues have some work around like gists creating correct permissions for proxy models, widgets to display the permissions in a translated Tabular format (django-tabular-permissions)
But the problems are still there. 
And the current implementation in itself is some what naive, only add , change , delete 
Maybe i can delete only the records created by me, maybe i can delete but not older then 1 day unless i'm superuser

I want to suggest a complete Permission makeover
Basically a new model / db table for User permissions which look something like this (and another one for the groups of course.)

user_id | contenttype_id | add  | change| delete
1           | 1                      | True | True    | False

The new model can be swap-able (like the User model) so end developers might add more specified fields beside the add , change,  delete like (can edit other users entries, limit to date etc.) 
It might be also advised to create your own Permission model at the start of the project (like what is happening now with the user model) 

And the current Permissions table can be used for the custom permissions .

I understand that this is might not be the most backward compatible solution (although if accepted by you, we can figure this out, using data migrations or something)

But Permissions in Django have been dragging for far too long, and delaying fixing them if not helping.
I see the new simplified url (and letting go of the regular expressions- at least up front) and i say wow, things can change. :-)

Looking forward for your much appreciated input, ideas & discussion.

Thank you for your time reading this and Best wishes to all of you.


Ramez

[ludovic coues]

There are a lot of issue with your new permissions.

Some people have been asking for a view permission in admin. With
current system, all one have to do is add a permission per model. With
your proposal, the whole system have to be ditched in favor of a more
flexible one.

I have also seen production code using permission like is_something.
Yeah, sure, it's not semantically correct. Being a bot or a moderator
or a senior user is not a permission. But current permission system
work nicely for that kind of stuff.

Yeah, sure, people can swap the model like with user. But I have seem
more often code adding a foreign key pointing to the user rather than
swapping the model. I doubt that kind of solution will work with stuff
like user.has_perm().

In a nutshell, what you propose will break a lot of code, require more
work from developer, won't really help with translation and the only
help with the widget because you are cutting most of the useful stuff
out of the permission system.

> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bbdf1910-6b89-4568-8c1b-a681b5807871%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Cordialement, Ludovic Coues
+33 6 14 87 43 42

[Ramez Ashraf]

My proposal is mainly about re-thinking how permissions work with Django as a whole, as It's not the most perfect thing. And fixing it in a backward compatible way is next to impossible, so i would say let's revolutionize it and try to ease the transition. 

Regarding adding a view permission (for example) , with my approach, the developer would have to change the Base model the Permission is inheriting from (Or go and swap the model all together as with user).

With the new advice from Django to create own user model at the start of each project (even if it's not needed), maybe we will start see more Swapped Users models then what we see now.

Permission like `can_do_something` will (and should) still be supported.

Regarding User.has_perm, i think the method can be enhanced to accept model instance, or model_name and the action name. along side with the current implementation. 

My Approach will -of course- help with the translation as it there is no strings in the database.
Also the idea is about how to make the permissions flexible, to give the developers more accurate control.  
Again with this approach,  the developer can add extra field(s) to the "model permission" which can be anything which he/she can use.
I'll make a repo soon for demonstration.

> email to django-developers+unsubscribe@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.

> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bbdf1910-6b89-4568-8c1b-a681b5807871%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--

Cordialement, Ludovic Coues
+33 6 14 87 43 42

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/bKX_96v6qT0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAEuG%2BTa9UHwcRBWqohLPF2E6aEZrAFa%3DcaDW-7dSb1Mvidu_KQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Ramez Ashraf
Co-Founder and lead developer radev.io

[Ramez Ashraf]

After some some thoughts, i figured out that one route to change how permissions work in Django can be done by changing AUTHENTICATION_BACKENDS to a Custom ModelBackend Subclass that query for Permissions in a different way or from a different model / Table; And this solution can be implemented by each developer in their project if they dislike how the current permission work or it is simply not enough for them.

So maybe we can be satisfied with the current Permission implementation for some more time.

Hopefully this idea -customizing permissions by changing the ModelBackend Authentication , leaving the current Permission as it is-  might come in handy if anyone is not satisfied with the Django Permissions .
It can also be stated more clearly in the docs.

Greetings to you all.

[Jamesie Pic]

Have you tried of django-guardian ? What do you think about it ?

TBH I never actually used it (I've been doing Django for 9 years and have never used a permission table), but I think it does what you want.

From my experience, permissions are thought of something that can be calculated on the fly, and that's always been the shortest path. The only thing is, that you *should* then setup your base queryset per-model per-user OOAO, and then setup permissions per view.

Also, I don't understand how to make DRY code with the permission system: check a permission to display or not a link in the template, and also duplicate this check in the view's dispatch or something.

Nowadays, I prefer to set View.allow to a function I re-use, and call it in dispatch exactly like jinja templates and have a queryset generator that takes a user argument that all views in a given url router will use by default: List, Delete, Update, and so on, rather than maintaining boilerplate code to maintain a database table when something else changes in the database.

While I can understand how you could need django-guardian in some projects, I can understand why you want security as a feature in any project ;)

Keep up the great research !
<3