Le système d'autorisation de Django est très simple, il peut accorder des autorisations à des utilisateurs ou à des utilisateurs en groupe.
Le backend d'administration de Django utilise ce système d'autorisation, mais il peut également être utilisé dans votre propre code.
L'objet utilisateur a deux champs ManyToManyField, groupes et user_permissions
groups = models.ManyToManyField(Group, verbose_name=_('groups'),
blank=True, help_text=_ ( 'Les groupes auxquels cet utilisateur appartient. name="user_set", Related_query_name="user")
user_permissions = models.ManyToManyField(Permission,
verbose_name=_('autorisations utilisateur') , blank=True,
help_text=_('Autorisations spécifiques pour cet utilisateur.'),
Related_name= "user_set", Related_query_name="user")
Vous pouvez y accéder comme les autres modèles Django :
myuser.groups add(group, group, ...)
myuser.groups.remove(group, group, .. .)myuser.groups.clear()
myuser.user_permissions = [permission_list]
myuser.user_permissions.add(permission, permission, ...)
myuser.user_permissions.remove(permission, autorisation, ...)
myuser.user_permissions.clear()
Autorisations
class Permission(models.Model):
""" Le système d'autorisations fournit un moyen d'attribuer des autorisations à des
utilisateurs et groupes d'utilisateurs spécifiques.
Le système d'autorisation est utilisé par le site d'administration de Django, mais peut également être
utile dans votre propre code. Le site d'administration de Django utilise les autorisations comme suit :
- Les limites d'autorisation "ajouter". la possibilité de l'utilisateur d'afficher le formulaire "ajouter"
et d'ajouter un objet.
- L'autorisation "supprimer" limite la possibilité de supprimer un objet.
Les autorisations sont définies globalement par type d'objet. , pas par objet spécifique
instance. Il est possible de dire "Mary peut changer les actualités", mais il n'est
actuellement pas possible de dire "Mary peut changer les actualités, mais seulement celles
celles qu'elle a créées elle-même. " ou "Mary ne peut modifier que les actualités qui ont un
certain statut ou une certaine date de publication."
Trois autorisations de base -- ajouter, modifier et supprimer -- sont automatiquement
créées pour chaque modèle Django .
"""
name = models.CharField(_( 'name'), max_length=255)
content_type = models.ForeignKey(ContentType)
codename = models.CharField(_(' codename'), max_length=100)
objects = PermissionManager()
class Meta:
verbose_name = _('permission')
verbose_name_plural = _('permissions')
unique_together = (('content_type', 'codename'),)
order ing = ('content_type__app_label', 'content_type__model',
six. Text_type (self.Content_type.app_label),
Six.text_type ( Self.Content_type),
SIX.Text_type (Self.Name))
DEF Natural_key (Self):
Return ( self.codename,) self.content_type.natural_key()
natural_key .dependencies = ['contenttypes.contenttype']
champs champs
nom : obligatoire. 50 caractères ou moins, par exemple, « Can Vote »
content_type : obligatoire, une référence à la table de base de données django_content_type, qui contient des enregistrements pour chaque modèle de l'application.
nom de code : obligatoire, 100 caractères ou moins, par exemple "can_vote".
Si vous souhaitez créer des autorisations pour un modèle :
à partir de django.db importer des modèles
class Vote(models.Model):
...
class Meta :
permissions = (("can_vote", "Can Vote"),)
Si ce modèle est dans l'application foo, les autorisations sont exprimées sous la forme 'foo. can_vote' , vérifiez si un utilisateur dispose des autorisations myuser.has_perm('foo.can_vote')
Autorisations par défaut autorisations par défaut
Si django.contrib.auth a été configuré dans INSTALLED_APPS, il sera garanti. Chaque modèle Django dans les applications installées crée 3 autorisations par défaut : ajouter, modifier et supprimer.
Ces autorisations sont créées la première fois que vous exécutez manage.py migrate (syncdb avant 1.7). À ce moment-là, tous les modèles auront des autorisations établies. Les nouveaux modèles créés après cela disposeront de ces autorisations par défaut créées lors de la nouvelle exécution de manage.py migrate. Ces autorisations correspondent aux comportements de création, de suppression et de modification dans l'interface de gestion de l'administrateur.
Supposons que vous ayez une application foo avec une barre de modèle, vous pouvez utiliser la méthode suivante pour tester les autorisations de base :
ajouter : user.has_perm('foo.add_bar')
change : user.has_perm('foo.change_bar')
delete : user.has_perm('foo.delete_bar')
Le modèle d'autorisation n'est généralement pas utilisé directement.
Groupes
Le groupe existe également en tant que modèle :
@python_2_unicode_compatible
class Group(models.Model):
"""
Les groupes sont une manière générique de catégoriser les utilisateurs pour appliquer des autorisations, ou
une autre étiquette, à ces utilisateurs. Un utilisateur peut appartenir à n'importe quel nombre de
groupes.
Un utilisateur d'un groupe possède automatiquement tous les éléments. autorisations accordées à ce
groupe. Par exemple, si le groupe Éditeurs du site dispose de l'autorisation
can_edit_home_page, tout utilisateur de ce groupe aura cette autorisation.
Au-delà des autorisations, les groupes sont un moyen pratique de le faire. catégorisez les utilisateurs pour
leur appliquer une étiquette ou une fonctionnalité étendue. Par exemple, vous
pouvez créer un groupe « Utilisateurs spéciaux » et vous pouvez écrire du code qui
fera des choses spéciales à ces utilisateurs -. - comme leur donner accès à une
partie réservée aux membres de votre site, ou leur envoyer des e-mails
réservés aux membres.
"""
name = models.CharField(_(' name '), max_length=80, unique=True)
permissions = models.ManyToManyField(Permission,
verbose_name=_('permissions'), blank=True)
objects = GroupManager()
class Meta :
verbose_name = _('group')
verbose_name_plural = _('groups')
def __str__(self):
return self.name
def natural_key(self):
return (self.name,)
fields :
name : obligatoire, 80 caractères ou moins, par exemple, « Utilisateurs géniaux ».
permissions:ManyToManyField à Permission
group.permissions = [permission_list]
group.permissions.add(permission, permission, ...)
group.permissions.remove( permission, permission, ...)
group.permissions.clear()
Création d'autorisations par programmation
En plus d'utiliser la méta modèle pour créer des autorisations, vous pouvez également utiliser code créer directement.
Par exemple, créez une autorisation can_publish pour le modèle BlogPost dans l'application myapp :
from myapp.models import BlogPost
from django.contrib.auth.models import Group, Permission
depuis django.contrib.contenttypes.models importez ContentType
content_type = ContentType.objects.get_for_model(BlogPost)
permission = Permission.objects.create(codename='can_publish',
name= 'Peut publier des messages',
Content_type = Content_type)
les autorisations peuvent être accordées à un objet utilisateur via ses user_permissions ou à un groupe via son attribut Permissions.
Mise en cache des autorisations
Les autorisations de l'utilisateur peuvent être mises en cache lorsqu'elles sont cochées. Si une nouvelle autorisation est accordée à un utilisateur, elle ne sera pas vérifiée si elle est vérifiée immédiatement. Le moyen le plus simple consiste à récupérer l’objet User.
depuis django.contrib.auth.models import Permission, User
depuis django.shortcuts import get_object_or_404
def user_gains_perms(request, user_id):
user = get_object_or_404(User, pk=user_id) )
#La vérification des autorisations mettra en cache l'ensemble d'autorisations actuel
user.has_perm('myapp.change_bar')
permission = Permission.objects.get(codename='change_bar')
user .user_permissions.add(permission)
# Vérifier l'ensemble de cache d'autorisations
user.has_perm('myapp.change_bar') # False
# Demander une nouvelle instance
user = get_object_or_404( Utilisateur, pk=user_id)
# Le cache des autorisations est repeuplé à partir de la base de données
user.has_perm('myapp.change_bar') # True
...
Décorateur d'autorisations
permission_required(perm[, login_url=None, raise_exception=False])
Vérifie si l'utilisateur dispose d'une certaine autorisation, similaire à @login_required()
de django.contrib.auth.decorators import permission_required
@permission_required('polls.can_vote', login_url='/loginpage/')
def my_view(request):
…
Autorisations dans le modèle
Les autorisations de l'utilisateur sont stockées dans la variable du modèle {{ perms }}, qui est une instance de django.contrib.auth.context_processors.PermWrapper.
{{ perms.foo }}
L'attribut unique ci-dessus est le proxy de User.has_module_perms. Si l'utilisateur dispose d'une autorisation dans foo, elle est True
{{ perms.foo.can_vote }}
La requête d'attribut à deux niveaux ci-dessus est le proxy de User.has_perm, Vrai si l'utilisateur dispose de l'autorisation foo.can_vote.
Par exemple :
{% if perms.foo %}
Vous êtes autorisé à faire quelque chose dans l'application foo.
p>Vous pouvez conduire !
Vous n'êtes pas autorisé à faire quoi que ce soit dans l'application foo.< /p>
{% endif %}
ou :
{% if 'foo' en perms %}
{% if 'foo.can_vote' en perms %} Pour plus de contenu connexe, veuillez consulter le site Web PHP en chinois (www .php.cn) !