superuser having all permissions makes perm checking messy

115 views
Skip to first unread message

guettli

unread,
Mar 16, 2017, 5:29:21 AM3/16/17
to Django users
This is not a question, just a feeling. I want to know if you feel the same pain.

Checking for permission in django is done in two steps:

 check1: check if user is superuser, then user is allowed.
 check2: check if user has the given permission.

This OR is solvable. It's easy to code. It is just a simple "if".

The OR can be done in SQL, too.... But not much better.

But somehow it makes my code messy.

I would like to get the answer directly from postgres/DB, I don't write a condition.

I want it to be straight forward.

In our custom code we already skip check1 and do only check2.

But this makes the whole situation not much better.

I am just speaking out my thoughts.

Dear django (core) developer: I like django very much and it is a great
framework which I use daily with joy. Don't get me wrong!

Unfortunately I have no clue which strategy could lead me to the goal if this particular issue without
doing stuff in my code completely different than django does. I want to avoid doing uncommon things
and stick to upstream.

Regards,
  Thomas Güttler




Jani Tiainen

unread,
Mar 16, 2017, 10:29:15 AM3/16/17
to django...@googlegroups.com

Hi,

You don't need to check for superuser explicitly Django does that when you check does user have a permission and returns true for all perm checks.

So it's just simple check.

Unless you meant something else, maybe giving a sample code would help understand your problem better.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d629dba5-cc73-4625-9d91-92741b7010a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Jani Tiainen

guettli

unread,
Mar 17, 2017, 4:53:47 AM3/17/17
to Django users
It's not a problem. It something else. I am missing the right words ... I know how to use conditions in python or the equivalent sql operations.

I am sure that my code would be simpler if the superuser would not have all permissions.

I am sure if I want to go this way, since django does it different.

It's not a problem. Maybe it is event not a thought of my brain. It is more a feeling or big dream: simpler code with less conditions.

Regards,
  Thomas

Andréas Kühne

unread,
Mar 17, 2017, 5:56:39 AM3/17/17
to django...@googlegroups.com
I also think you are talking about to different things. 

Thomas, I get a feeling you are not using the default permissions system built into django, but rather using your own. Regardless of how you do it - you could just add a method on the user object that is :

def has_permission(self, permission)

In that method you can do checking for the super user and then also for the specifik permission you need. That way you only check it in one place and it won't ruin your code.  

Regards,

Andréas

To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

James Schneider

unread,
Mar 17, 2017, 6:26:59 AM3/17/17
to django...@googlegroups.com


On Mar 17, 2017 1:53 AM, "guettli" <guettli...@thomas-guettler.de> wrote:
It's not a problem. It something else. I am missing the right words ... I know how to use conditions in python or the equivalent sql operations.

I am sure that my code would be simpler if the superuser would not have all permissions.

If you're coding your own authorization system, then the idea of a superuser doesn't need to exist.

If you are using Django's built-in authorization system, the same rule effectively applies if you don't assign any user the superuser attribute.



I am sure if I want to go this way, since django does it different.

Authentication and authorization are difficult topics to tackle. I'd suggest looking at other Django packages that deal with these topics, each with their own philosophy (possibly matching what you are looking for), and most of which are maintained and battle tested on real sites.


Learning the built-in system or using one of these packages will likely be easier and yield better results in the long run.


It's not a problem. Maybe it is event not a thought of my brain. It is more a feeling or big dream: simpler code with less conditions.

That's a great goal, and I hope you get there. It's possible that your requirements for permissions can be done with a few simple conditions. For a majority of applications, though, it often is not that simple. I think everyone would rather have a simpler system.

The built-in permission system that Django uses is actually relatively simple (IMO), and only contains a couple of conditional statements (are you a super user or do you have permission X in your list of permissions). The most complex portion is probably the nested object wrappers that allow permission checks directly within templates, and in reality that code has nothing to do with the permission check itself.

You'll probably find that your requirements over time will outgrow your simple permission system if your application has even a small amount of success.

-James

Melvyn Sopacua

unread,
Mar 18, 2017, 1:00:14 AM3/18/17
to django...@googlegroups.com

On Thursday 16 March 2017 02:29:21 guettli wrote:

 

> In our custom code we already skip check1 and do only check2.

 

Why do you even do these checks?

There's a view decorator and class-based view mixin. All you need to do is make good groups and users and the rest follows.

 

If you want to define a new permission type, you can do it in the model meta class. Not one place requires manual permission checks - when you stick to the model level.

 

If you need to enforce permissions at the model instance level, then don't reinvent the wheel. There's a few packages out there, who have already solved the problem - Django Guardian being one of them.

--

Melvyn Sopacua

guettli

unread,
Mar 20, 2017, 9:28:38 AM3/20/17
to Django users


Am Samstag, 18. März 2017 06:00:14 UTC+1 schrieb Melvyn Sopacua:

On Thursday 16 March 2017 02:29:21 guettli wrote:

 

> In our custom code we already skip check1 and do only check2.

 

Why do you even do these checks?


Good question.

I want to get all users which have a given permission.

Here is one implementation of it.  https://code.djangoproject.com/ticket/18763

The resulting SQL uses several OUTER JOINS resulting in this issue: https://code.djangoproject.com/ticket/27260

We work-around it by serializing to IDs and then using the IDs in the next .filter() ... not nice but works.

Regards,
  Thomas Güttler






 
Reply all
Reply to author
Forward
0 new messages