Supprimer (ou masquer) les Autorisations par défaut de Django

Je suis l'élaboration d'un Django app qui va avoir deux de l'administration backends. L'un pour l'usage quotidien par les utilisateurs "normaux" et celui par défaut pour les tâches plus complexes et pour les développeurs.

L'application utilise certaines autorisations personnalisées, mais aucun de ceux par défaut. Donc, je suis actuellement à la recherche d'un moyen de supprimer les autorisations par défaut, ou au moins un moyen de les cacher de la "quotidienne" admin backend sans grandes modifications.

  • Je n'ai jamais essayé, donc j'hésite à le mettre vers le bas comme une réponse, mais vous pouvez probablement supprimer les entrées de la base pour eux. Si votre administrateur les utilisateurs sont classés comme les superutilisateurs, on présume qu'ils ont toutes les autorisations de toute façon (je pense), et donc vous ne devriez pas les dossiers. Pas de promesses, mais.
  • oui, si elles sont les superutilisateurs chaque appel à une "a la permission" méthode renvoie true. Mais je ne pense pas que c'est l'idée puisque vous utilisez des autorisations personnalisées. Ne vous empêchez le Django admin de vérifier les autorisations par défaut? Parce que si un utilisateur ne dispose pas des autorisations par défaut pour un certain objet, il n'apparaît pas dans l'admin.
InformationsquelleAutor Martin Thurau | 2011-05-19
  1. 10

    Une nouvelle fonctionnalité introduite dans Django 1.7 est la capacité de définir les autorisations par défaut. Comme indiqué dans le la documentation si vous définissez ce paramètre à vide aucun des autorisations par défaut sera créé.

    Un exemple serait:

    class Blar1(models.Model):
    id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=255, unique = True, blank = False, null = False, verbose_name= "Name")

    class Meta:
        default_permissions = ()
    • Mais vous ne pouvez pas utiliser cette méthode pour éviter de Django créer des autorisations pour ses propres modèles comme la Session, ni travaux pour tiers modèles.
    • La cause n'est pas, et vous ne devriez pas être jouer avec eux de toute façon. Quelle raison auriez-vous besoin de cela?
    • Je ne pense pas que "vous ne devriez pas être jouer avec eux" est correct, si vous n'êtes pas à l'aide de django admin vous n'avez pas besoin de ces autorisations. Suppression manuelle n'a rien ici.
    • "Quelle raison auriez-vous besoin de cela?" Je veux utiliser mon totalement personnalisé système d'autorisation sur le dessus de django autorisations. Quand je vous montre une liste de toutes les autorisations d'utilisateur admin par exemple, de sorte qu'il peut attribuer des autorisations à des utilisateurs je dois manuellement filtrer django interne des autorisations. Il est tout simplement ennuyeux.
    InformationsquelleAutor oden
  2. 18

    Mise à JOUR: Django 1.7 en charge la personnalisation de les autorisations par défaut

    Réponse Originale À Cette Question

    Ce qui suit est valable pour Django avant la version 1.7

    C'est une fonctionnalité standard de la auth contrib application.

    Il gère le post_syncdb signal et crée les autorisations (la norme 3: ajouter, changement, supprimer, plus tous ceux personnalisées) pour chaque modèle; ils sont stockés dans le auth_permission table dans la base de données.

    Donc, , ils seront créés chaque fois que vous exécutez le syncdb de commande de gestion de

    Vous avez quelques choix. Aucun n'est vraiment élégant, mais vous pouvez envisager d':

    1. Tomber la auth contrib application et de fournir votre propre backend d'authentification.

      Conséquences -> vous perdrez de l'administration et d'autres applications personnalisées construit sur l'authentification de l'Utilisateur modèle, mais si votre application est hautement personnalisé qui pourrait être une option pour vous

    2. Prépondérant sur le comportement de la post_syncdb signal à l'intérieur de l'auth application (à l'intérieur de \django\contrib\auth\management__init__.py fichier)

      Conséquences -> être conscient que sans les permissions de base, le Django de l'interface d'administration ne sera pas en mesure de travailler (et peut-être d'autres choses aussi).

    3. La suppression des permissions de base (ajouter, changement, supprimer) pour chaque modèle à l'intérieur de la auth_permission table (manuellement, avec un script, ou quoi que ce soit).

      Conséquences -> vous perdrez l'admin de nouveau, et vous aurez besoin de les supprimer chaque fois que vous exécutez syncdb.

    4. La construction de votre propre l'Autorisation de l'application/système (avec votre propre décorateurs, middlewares, etc..) ou à l'extension de l'existant.

      Conséquences -> aucun, si vous le construisez, c'est bien - c'est l'un des plus propres solutions, à mon avis.

    Un examen final: la modification de la contrib applications ou framework Django lui-même n'est jamais considéré comme une bonne chose: tu risque de casser quelque chose et vous aurez des moments difficiles si vous devez mettre à niveau vers une version plus récente de Django.

    Donc, si vous voulez être aussi propre que possible, envisagez de déployer votre propre système d'autorisation, ou à l'extension de la norme (django-gardien est un bon exemple d'une extension de django autorisations). Il ne prendra pas beaucoup d'effort, et vous pouvez construire, la façon dont il se sent le droit pour vous, de surmonter les limites de la norme django système d'autorisation. Et si vous faites un bon travail, vous pourriez aussi envisager de l'open source pour permettre à d'autres personnes à l'aide de/l'amélioration de votre solution =)

    • Eh bien, puis-je la vie avec eux.
    • Mais vous ne pouvez pas utiliser la méthode de mise à jour pour éviter de Django créer des autorisations pour ses propres modèles comme la Session, ni travaux pour tiers modèles.
    InformationsquelleAutor BFil
  3. 16

    J'ai du mal avec ce même problème depuis un moment et je pense que je suis venu avec une solution propre. Voici comment masquer les autorisations pour Django auth application:

    from django.contrib import admin
from django.utils.translation import ugettext_lazy as _
from django import forms
from django.contrib.auth.models import Permission

class MyGroupAdminForm(forms.ModelForm):
    class Meta:
        model = MyGroup

    permissions = forms.ModelMultipleChoiceField(
        Permission.objects.exclude(content_type__app_label='auth'), 
        widget=admin.widgets.FilteredSelectMultiple(_('permissions'), False))


class MyGroupAdmin(admin.ModelAdmin):
    form = MyGroupAdminForm
    search_fields = ('name',)
    ordering = ('name',)

admin.site.unregister(Group)
admin.site.register(MyGroup, MyGroupAdmin)

    Bien sûr, il peut facilement être modifié pour masquer les autorisations que vous souhaitez. Laissez-moi savoir si cela fonctionne pour vous.

    • Qu'entendez-vous avec le modèle appelé "MyGroup"?
    InformationsquelleAutor pmdarrow
  4. 5

    ShadowCloud a donné un bon aperçu. Voici une façon simple d'atteindre votre objectif.

    Ajouter ces ligne dans votre admin.py:

    from django.contrib.auth.models import Permission
admin.site.register(Permission)

    Vous pouvez maintenant ajouter/modifier/supprimer des autorisations dans l'admin. Supprimer la inutilisés et quand vous avez ce que vous voulez, revenir en arrière et supprimer ces deux lignes de admin.py.

    Comme il a été mentionné par d'autres, un syncdb de tout mettre en arrière.

    • Parfait! C'est beaucoup plus simple que la randonnée à travers la base de données!
    InformationsquelleAutor Brandon
  5. 2

    Construit au-dessus de la solution par @pmdarrow, je suis venu avec une relativement propre solution de patch le Django admin vues.

    Voir: https://gist.github.com/vdboor/6280390

    Elle s'étend de la User et Group admin pour masquer certaines autorisations.

    InformationsquelleAutor vdboor
  6. 2

    Vous ne pouvez pas supprimer facilement les autorisations (de sorte que syncdb de ne pas les mettre à l'arrière), mais vous pouvez les masquer à partir de l'interface d'administration. L'idée est, comme décrit par d'autres, pour remplacer l'administrateur de forme, mais vous devez le faire pour les utilisateurs et les groupes.
    Ici, c'est le admin.py avec la solution:

    from django import forms
from django.contrib import admin
from django.contrib.auth.models import Permission
from django.contrib.auth.models import User, Group
from django.contrib.auth.admin import GroupAdmin, UserAdmin
from django.contrib.auth.forms import UserChangeForm
#
# In the models listed below standard permissions "add_model", "change_model"
# and "delete_model" will be created by syncdb, but hidden from admin interface.
# This is convenient in case you use your own set of permissions so the list
# in the admin interface wont be confusing.
# Feel free to add your models here. The first element is the app name (this is
# the directory your app is in) and the second element is the name of your model
# from models.py module of your app (Note: both names must be lowercased).
#
MODELS_TO_HIDE_STD_PERMISSIONS = (
("myapp", "mymodel"),
)
def _get_corrected_permissions():
perms = Permission.objects.all()
for app_name, model_name in MODELS_TO_HIDE_STD_PERMISSIONS:
perms = perms.exclude(content_type__app_label=app_name, codename='add_%s' % model_name)
perms = perms.exclude(content_type__app_label=app_name, codename='change_%s' % model_name)
perms = perms.exclude(content_type__app_label=app_name, codename='delete_%s' % model_name)
return perms
class MyGroupAdminForm(forms.ModelForm):
class Meta:
model = Group
permissions = forms.ModelMultipleChoiceField(
_get_corrected_permissions(),
widget=admin.widgets.FilteredSelectMultiple(('permissions'), False),
help_text = 'Hold down "Control", or "Command" on a Mac, to select more than one.'
)
class MyGroupAdmin(GroupAdmin):
form = MyGroupAdminForm
class MyUserChangeForm(UserChangeForm):
user_permissions = forms.ModelMultipleChoiceField(
_get_corrected_permissions(),
widget=admin.widgets.FilteredSelectMultiple(('user_permissions'), False),
help_text = 'Hold down "Control", or "Command" on a Mac, to select more than one.'
)
class MyUserAdmin(UserAdmin):
form = MyUserChangeForm
admin.site.unregister(Group)
admin.site.register(Group, MyGroupAdmin)
admin.site.unregister(User)
admin.site.register(User, MyUserAdmin)
    InformationsquelleAutor Nikolay Fedorovskiy
  7. 0

    Si vous créez votre propre gestion des utilisateurs backend et que vous souhaitez uniquement afficher vos autorisations personnalisées vous pouvez filtrer les autorisations par défaut par l'exclusion de l'autorisation avec un nom qui commence par "Peut".

    AVERTISSEMENT:
    Vous devez vous rappeler de ne pas le nom de vos autorisations de départ avec "Peut"!!!!
    Si ils décident de changer la dénomination de la convention de cela pourrait ne pas fonctionner.

    Avec crédit à pmdarrow c'est la façon dont je l'ai fait dans mon projet:

    from django.contrib.auth.forms import UserChangeForm
from django.contrib.auth.models import Permission
from django.contrib import admin    
class UserEditForm(UserChangeForm):
class Meta:
model = User
exclude = (
'last_login',
'is_superuser',
'is_staff',
'date_joined',
)
user_permissions = forms.ModelMultipleChoiceField(
Permission.objects.exclude(name__startswith='Can'), 
widget=admin.widgets.FilteredSelectMultiple(_('permissions'), False))
    InformationsquelleAutor Taco Python
  8. 0

    Si vous souhaitez empêcher Django de créer des autorisations, vous pouvez bloquer les signaux envoyés.

    Si vous mettez cela dans une gestion/init.py dans n'importe quelle application, il va se lier avec le gestionnaire de signal avant de l'auth cadre a une chance (en prenant avantage de la dispatch_uid anti-rebond).

    from django.db.models import signals
def do_nothing(*args, **kwargs):
pass
signals.post_syncdb.connect(do_nothing, dispatch_uid="django.contrib.auth.management.create_permissions")
signals.post_syncdb.connect(do_nothing, dispatch_uid="django.contrib.auth.management.create_superuser")
    InformationsquelleAutor Aidan