Solution au problème selon lequel les modèles Django ne peuvent pas utiliser les variables permanentes

Cet article vous présente principalement la méthode pour résoudre le problème du modèle Django qui ne peut pas utiliser les variables permanentes. L'article le présente en détail à travers un exemple de code. Il a une certaine valeur d'apprentissage de référence pour l'étude ou le travail de chacun. qui en a besoin peut suivre Apprenons avec l’éditeur.

Avant-propos

Cet article présente principalement la solution au problème selon lequel le modèle Django ne peut pas utiliser les variables permanentes, et le partage pour votre référence et votre étude . Ci-dessous Pas grand chose à dire, jetons un œil à l'introduction détaillée.

Solution :

Tout d'abord, lorsque vous utilisez le système de gestion des autorisations intégré de Django, ajoutez

aux paramètres Fichier .py

INSTALLED_APPS添加:
'django.contrib.auth',

 
MIDDLEWARE添加:
'django.contrib.auth.middleware.AuthenticationMiddleware',

'django.contrib.auth.context_processors.auth',
TEMPLATES = [
 {
  'BACKEND': 'django.template.backends.django.DjangoTemplates',
  'DIRS': [os.path.join(BASE_DIR, 'templates')],
  'APP_DIRS': True,
  'OPTIONS': {
   'context_processors': [
    'django.template.context_processors.debug',
    'django.template.context_processors.i18n',
    'django.template.context_processors.media',
    'django.template.context_processors.static',
    'django.template.context_processors.tz',
    'django.contrib.messages.context_processors.messages',
    'django.template.context_processors.request',
    'django.contrib.auth.context_processors.auth',
   ],
  },
 },
]

Comment vérifier les autorisations dans les modèles ?

Selon les instructions du site officiel https://docs.djangoproject.com/en/1.11/topics/auth/default/#permissions, les autorisations des utilisateurs connectés sont enregistrées dans le template {{ perms }} variable , est une instance du proxy de modèle d'autorisation django.contrib.auth.context_processors.PermWrapper Pour plus de détails, vous pouvez consulter le code source de django/contrib/auth/context_processors.py

Cas de test :

Lors du test, il a été constaté que la variable

n'existait pas du tout et qu'il n'y avait pas de sortie, eh bien, nous ne pouvons obtenir que le code source de ; Déboguer Django {{ perms }}

def auth(request):
 """
 Returns context variables required by apps that use Django's authentication
 system.

 If there is no 'user' attribute in the request, uses AnonymousUser (from
 django.contrib.auth).
 """
 if hasattr(request, 'user'):
  user = request.user
 else:
  from django.contrib.auth.models import AnonymousUser
  user = AnonymousUser()
 print(user, PermWrapper(user), '-----------------------')
 return {
  'user': user,
  'perms': PermWrapper(user),
 }

En testant l'interface d'accès, j'ai découvert que certaines interfaces ont des informations d'autorisation d'impression, et d'autres non. Il semble que j'ai soudainement réalisé que

L'interface qui peut imprimer les informations d'autorisation renvoie :

 return render(request, 'fms/fms_add.html', {'request': request, 'form': form, 'error': error})

Impossible d'imprimer l'autorisation :

.

 return render_to_response( 'fms/fms.html', data)

Différence entre render et render_to_response

render est un moyen plus pratique de rendre des modèles que render_to_reponse. Il utilisera automatiquement RequestContext, tandis que ce dernier doit être ajouté manuellement :

return render_to_response(request, 'fms/fms_add.html', {'request': request, 'form': form, 'error': error},context_instance=RequestContext(request))

où RequestContext est une sous-classe de

Il accepte django.template.Context et <.>, afin que le contexte soit rempli et rendu au modèle. Le problème est déjà clair En raison de l'utilisation de la méthode request, le modèle ne peut pas être utilisé sans ajouter manuellement context_processors. >

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!