Code

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#18600 closed New feature (worksforme)

group_required decorator

Reported by: daniel.walz@… Owned by: nobody
Component: contrib.auth Version: 1.4
Severity: Normal Keywords: group authorization
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

To use view authorization together with groups, a decorator is needed in the style of @login_required.
I added to contrib.auth.models a function to the class User named is_in_group(group). For convenience the function handles the argument group as instance of Group, the name or the primary key of the group.
In contrib.auth.decorators I added a new decorator group_required(group).

Attachments (1)

group_required_decorator.diff (2.5 KB) - added by daniel.walz@… 2 years ago.

Download all attachments as: .zip

Change History (7)

Changed 2 years ago by daniel.walz@…

comment:1 Changed 2 years ago by aaugustin

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

The expected way to achieve this is to define a custom permission, give it to your group and use @permission_required.

@group_required is a bad idea because it introduces a tight coupling between the groups in your database and your code.

Last edited 2 years ago by aaugustin (previous) (diff)

comment:2 Changed 2 years ago by ccurvey

I'm confused. Having a tight coupling with the rows in the groups table is bad, but having a tight coupling with the rows in the permissions table is OK?

It the "Django Way" is going to be "use permissions", then we need a way to create new permissions through the admin interface (just as you can create groups through the admin interface.)

comment:3 Changed 2 years ago by aaugustin

Let me try to clarify this.


Permissions are defined in code and used by code -- mostly by the permission_required decorator.

They're copied to the database during syncdb for convenience. It makes it easier to attribute them to groups. But that's just a copy, the authoritative version is still defined by the Python code.

We must not make it possible to create permissions through the admin. Otherwise how could you be sure that the correct set of permissions -- those used by your code -- exist?


On the other hand, groups aren't defined in code (unless you've customized things, in which case you can write your own group_required).

comment:4 Changed 2 years ago by daniel.walz@…

I just dropped the use of the group_required to follow your suggestion.
Although I found it very unhandy to create the permissions in the shell.
Do I understand it right, that the syncdb is creating the standard permissions from the model.py, or do I define prototypes for custom permissions anywhere in the code, where syncdb reads it and puts it into the auth tables?
If so I would be eger to know that, because that would be the way, I define the permission and the use of the permission in the same place i.e. the code. That would make sense to me.
If there is no such place and I have to create the (custom) permissions in the shell anyway, I would suggest to meke it possible to create the permissions in the admin interface and keep the staff out of that feature so that they can't mess with the system (and the administrator can do that anyway.

BTW. If someone wants to use my code, the AnonymousUser needs the method "def is_in_group(self, group): return False" to work... sorry for that.

comment:5 follow-up: Changed 2 years ago by aaugustin

My previous comment contains a link to the documentation of "how to create custom permissions" :)

Last edited 2 years ago by aaugustin (previous) (diff)

comment:6 in reply to: ↑ 5 Changed 2 years ago by daniel.walz@…

Replying to aaugustin:

My previous comment contains a link to the documentation of "how to create custom permissions" :)

Oops, thanks
I just overlooked it, because I read the answer in my mail, where the link was no link ;)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.