Re: New Permissions Scheme

2017-09-22 Thread 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

-- 
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-developers+unsubscr...@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/CAC6Op19xnSfM7KbJryJE5kYnY5BeSZ4tx8G5f3CvXEo0EU335Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: New Permissions Scheme

2017-09-22 Thread 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.





-- 
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-developers+unsubscr...@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/d69c8163-b57e-4771-b7c0-d66ffbe7faa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: New Permissions Scheme

2017-09-21 Thread 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.


On Thu, Sep 21, 2017 at 11:19 PM, ludovic coues  wrote:

> 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.
>
> 2017-09-21 22:14 GMT+02:00 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
> >
> >
> >
> >
> >
> >
> > --
> > 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-developers+unsubscr...@googlegroups.com.
> > To post to 

New Permissions Scheme

2017-09-21 Thread 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






-- 
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-developers+unsubscr...@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.