|
|
相关文章推荐
Toggle theme (current theme: auto)
Toggle theme (current theme: light)
Toggle theme (current theme: dark)
Toggle Light / Dark / Auto color theme
Toggle theme (current theme: auto)
Toggle theme (current theme: light)
Toggle theme (current theme: dark)
Toggle Light / Dark / Auto color theme
Infrastructure de contrôle système ¶
L’infrastructure de contrôle système est un ensemble de contrôles statiques pour valider les projets Django. Elle détecte les problèmes courants et fournit des conseils sur la façon de les corriger. L’infrastructure est extensible de sorte que vous pouvez facilement ajouter vos propres contrôles.
Pour plus de détails sur la façon d’ajouter vos propres contrôles et les intégrer aux contrôles systèmes de Django, consultez le Guide thématique sur la vérification système .
Référence de l’API ¶
CheckMessage
¶
class
CheckMessage
(
level
,
msg
,
hint
=
None
,
obj
=
None
,
id
=
None
)
¶
Les avertissements et les erreurs signalés par les contrôles systèmes doivent être des instances de
CheckMessage
. Une instance encapsule une seule erreur à signaler ou un seul avertissement. Elle fournit également des indicateurs et le contexte applicables au message, et un identifiant unique qui est utilisé à des fins de filtrage.
Les arguments du constructeur sont :
level
DEBUG
,
INFO
,
WARNING
,
ERROR
,
CRITICAL
. Si le niveau est supérieur ou égal à
ERROR
, Django empêchera l’exécution des commandes de gestion. Les messages avec un niveau inférieur à
ERROR
(i.e. les avertissements) sont présentés dans la console, mais peuvent être réduits au silence.
msg
hint
None
peut être utilisée.
obj
__str__()
. La méthode est utilisée lors de la collecte de tous les messages et son résultat précède le message.
id
applabel.X001
, où
X
est l’une des lettres
CEWID
, indiquant la gravité du message (
C
pour critique,
E
pour les erreurs et ainsi de suite). Le numéro peut être attribué par l’application, mais doit être unique au sein de cette application.
Il existe des sous-classes pour faciliter la création des messages avec les niveaux de base. Lorsque vous les utilisez, vous pouvez omettre le paramètre
level
car il est sous-entendu par le nom de la classe.
Debug
(
msg
,
hint
=
None
,
obj
=
None
,
id
=
None
)
¶
Étiquettes prédéfinies ¶
Les contrôles systèmes de Django sont organisés en utilisant les étiquettes suivantes :
admin
: contrôles de toutes les déclarations de sites d’administration.
async_support
: contrôle la configuration liée au code asynchrone.
caches
: contrôle la configuration liée aux caches (mémoire tampon).
compatibility
: identification de problèmes potentiels avec les mises à jour.
database
: vérifie des problèmes de configuration liés aux bases de données. Les contrôles de base de données ne sont pas exécutés par défaut car ils font plus que de l’analyse de code statique comme le font les autres contrôles. Ils ne sont lancés que par la commande
migrate
ou si vous indiquez des alias de base de données configurés avec l’option
database
lors de l’appel à la commande
check
.
files
: contrôle la configuration liée aux fichiers.
models
: contrôles régissant les définitions de modèles, champs et gestionnaires.
security
: contrôle la configuration liée à la sécurité.
signals
: contrôles des déclarations de signaux et des enregistrements de gestionnaires.
sites
: contrôle la configuration de
django.contrib.sites
.
staticfiles
: contrôle la configuration liée à
django.contrib.staticfiles
.
templates
: contrôle la configuration liée aux gabarits.
translation
: vérifie la configuration liée aux traductions.
urls
: contrôle la configuration des URL.
Certains contrôles peuvent être enregistrés sous plusieurs étiquettes.
Vérifications systèmes du noyau ¶
Gestion du code asynchrone ¶
Les contrôles suivants vérifient votre configuration concernant Gestion du code asynchrone :
Rétrocompatibilité ¶
Les contrôles de compatibilité alertent sur des problèmes potentiels pouvant se produire après une mise à jour de Django.
<pattern>
possède une route contenant
(?P<
, commençant par
^
ou se terminant par
$
. Il s’agit probablement d’un oubli lors du passage de
url()
à
path()
.
CSRF_TRUSTED_ORIGINS
doivent commencer par un protocole (généralement http://` ou
https://
), mais
<nom_hôte>
a été trouvé.
Caches ¶
Les contrôles suivants vérifient que le réglage
CACHES
est configuré correctement :
'default'
dans votre réglage
CACHES
.
<cache>
peut exposer votre cache ou permettre une corruption de vos données car son emplacement
LOCATION
correspond à, ou se trouve dans un des réglages
MEDIA_ROOT
/
STATIC_ROOT
/
STATICFILES_DIRS
.
LOCATION
du
<cache>
est relatif. Utilisez plutôt un chemin absolu.
Base de données ¶
MySQL et MariaDB ¶
Si vous utilisez MySQL ou MariaDB, les contrôles suivants seront effectués :
CharField
uniques d’avoir un attribut
max_length
> 255.
Ce contrôle a été transformé en
mysql.W003
dans Django 3.1 car la taille maximale réelle dépend de plusieurs facteurs.
<alias>
. Voir aussi
Définition de sql_mode
.
CharField
uniques d’avoir un attribut
max_length
> 255.
Gestion des fichiers ¶
Les contrôles suivants vérifient votre configuration concernant Gestion des fichiers :
FILE_UPLOAD_TEMP_DIR
se réfère au répertoire inexistant
<path>
.
Champs de modèle ¶
"__"
.
pk
est un mot réservé et ne peut pas être utilisé comme nom de champ.
choices
doit être un élément itérable (par ex. une liste ou un tuple).
choices
doit être un élément itérable contenant des tuples
(valeur
réelle,
nom
convivial)
.
db_index
ne peut contenir que
None
,
True
ou
False
.
null=True
.
validators
doivent être exécutables.
max_length
est trop court pour accueillir la plus longue valeur de
choices
(
<count>
caractères).
<champ>
doit être un objet exécutable plutôt qu’une instance afin qu’elle ne soit pas partagée entre toutes les instances de ce champ.
AutoField
doivent déclarer
primary_key=True
.
BooleanField
n’acceptent pas les valeurs nulles.
Ce contrôle est apparu avant la prise en charge des valeurs nulles ajoutée dans Django 2.1.
CharField
doivent définir un attribut
max_length
.
max_length
doit être un entier positif.
max_length
est ignoré lorsqu’il est utilisé pour un champ
<type
de
champ
entier>
.
DecimalField
doivent définir un attribut
decimal_places
.
decimal_places
doit être un entier non négatif.
DecimalField
doivent définir un attribut
max_digits
.
max_digits
doit être un entier positif.
max_digits
doit être supérieur ou égal à
decimal_places
.
FilePathField
doivent comporter l’un des deux attributs
allow_files
et
allow_folders
défini à
True
.
GenericIPAddressField
ne peuvent avoir
blank=True
si
null=False
, car les valeurs vides sont stockées sous forme de valeurs nulles.
auto_now
,
auto_now_add
et
default
sont mutuellement exclusives. Une seule de ces options doit être conservée.
<base_de_données>
ne prend pas en charge les index sur les colonnes
<type
données
champ>
.
<base_de_données>
ne gère pas les commentaires sur les colonnes (
db_comment
).
BinaryField
ne peut pas être une chaîne. Utilisez plutôt un contenu binaire.
<base
de
données>
ne prend pas en charge les champs
JSONField
.
<base_de_données>
ne prend pas en charge les collations sur les colonnes
<field_type>
.
IPAddressField
a été supprimé, sauf pour la prise en charge de migrations historiques.
IPAddressField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 1.9.
Ce contrôle apparaît dans Django 1.7 et 1.8
.
CommaSeparatedIntegerField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 2.0.
Ce contrôle apparaît avec Django 1.10 et 1.11
.
CommaSeparatedIntegerField
a été supprimé, sauf pour la prise en charge de migrations historiques.
FloatRangeField
est obsolète et sera supprimé dans Django 3.1.
Ce contrôle est apparu dans Django 2.2 et 3.0
.
NullBooleanField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 4.0.
Ce contrôle apparaît dans Django 3.1 et 3.2
.
NullBooleanField
a été supprimé, sauf pour la prise en charge de migrations historiques.
django.contrib.postgres.fields.JSONField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 4.0.
Ce contrôle apparaît dans Django 3.1 et 3.2
.
django.contrib.postgres.fields.JSONField
a été supprimé, sauf pour la prise en charge de migrations historiques.
django.contrib.postgres.fields.CICharField
est osbolète. Sa prise en charge (sauf pour les migrations historiques) sera supprimée dans Django 5.1.
django.contrib.postgres.fields.CIEmailField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 5.1.
django.contrib.postgres.fields.CITextField
est obsolète. Sa prise en charge (à l’exception des migrations historiques) sera supprimée dans Django 5.1.
Champs de type fichier ¶
unique
n’est pas un paramètre valable pour un champ
FileField
.
Ce contrôle est supprimé dans Django 1.11
.
primary_key
n’est pas un paramètre valable pour un champ
FileField
.
upload_to
de
FileField
doit être un chemin relatif, et non absolu.
ImageField
car Pillow n’est pas installé.
Champs de liaison ¶
<model>
, qui n’est pas installé ou qui est abstrait.
<étiquette_app>.<modèle>
qui a été substitué.
<modèle
lié>.<nom
accesseur>
pour
<étiquette_app>.<modèle>.<nom
champ>
entre en conflit avec le nom du champ
<étiquette_app>.<modèle>.<nom
champ>
.
<étiquette_app>.<modèle>.<nom_de_champ>
entre en conflit avec le nom du champ
<étiquette_app>.<modèle>.<nom_de_champ>
.
<modèle
lié>.<nom
accesseur>
pour
<étiquette_app>.<modèle>.<nom
champ>
entre en conflit avec l’accesseur inverse pour
<étiquette_app>.<modèle>.<nom
champ>
.
<étiquette_app>.<modèle>.<nom_de_champ>
entre en conflit avec le nom de requête inverse de
<étiquette_app>.<modèle>.<nom_de_champ>
.
<name>
n’est pas un nom
related_name
valable pour le champ
<modèle>.<nom_de_champ>
.
<étiquette_app>.<modèle>.<nom_de_champ>
a été déclaré avec une référence différée à
<étiquette_app>.<modèle>
, mais l’application
<étiquette_app>
n’est pas installée ou ne fournit pas de modèle
<modèle>
.
<nom_requête_inverse>
ne doit pas se terminer par un soulignement.
<nom_requête_inverse>
ne doit pas contenir
'__'
.
<champ1>
,
<champ2>
, … du modèle
<modèle>
n’a de contrainte unique.
<modèle>.<nom
de
champ>
doit être unique car il est référencé par une clé
ForeignKey
.
to_field
<nom_champ>
n’existe pas dans le modèle lié
<étiquette_app>.<modèle>
.
on_delete=SET_NULL
mais il ne peut pas être nul.
on_delete=SET_DEFAULT
mais il n’a pas de valeur par défaut.
ManyToManyField
ne peuvent pas être uniques.
<modèle>
qui n’a pas été installé.
<modèle>
mais il a plus de deux clés étrangères vers
<modèle>
, ce qui est ambigu. Vous devez indiquer laquelle des deux clés étrangères Django doit utiliser via le paramètre nommé
through_fields
.
<modèle>
mais il a plus d’une clé étrangère depuis
<modèle>
, ce qui est ambigu. Vous devez indiquer quelle clé étrangère Django doit utiliser via le paramètre nommé
through_fields
.
<modèle>
mais il a plus d’une clé étrangère vers
<modèle>
, ce qui est ambigu. Vous devez indiquer quelle clé étrangère Django doit utiliser via le paramètre nommé
through_fields
.
<modèle>
mais il n’a pas de clé étrangère vers
<modèle>
ou
<modèle>
.
through_fields
mais ne fournit pas le nom des deux champs de liaison qui doivent être utilisés pour la relation via
<modèle>
.
<through
model>
n’a pas de champ
<nom_de_champ>
.
<modèle>.<nom_de_champ>
n’est pas une clé étrangère vers
<modèle>
.
<nom
table>
entre en conflit avec le nom de la table de
<modèle>
/
<modèle>.<nom
champ>
.
null
n’a pas d’effet sur le champ
ManyToManyField
.
ManyToManyField
ne prend pas en charge le paramètre
validators
.
unique=True
sur un champ
ForeignKey
a le même effet que d’utiliser un champ
OneToOneField
.
limit_choices_to
n’a aucun effet sur le champ
ManyToManyField
avec modèle intermédiaire.
Ce contrôle est apparu avant Django 4.0.
<nom
table>
entre en conflit avec le nom de la table de
<modèle>
/
<modèle>.<nom
champ>
.
related_name
n’a aucun effet sur le champ
ManyToManyField
avec une relation symétrique, par ex. vers
self
.
db_comment
n’a aucun effet sur les champs
ManyToManyField
.
<swappable>
n’est pas sous la forme
étiquette_app.nom_app
.
<RÉGLAGE>
fait référence à
<modèle>
, qui n’est pas installé ou qui est abstrait.
<étiquette_app>.<modèle>
.
id
ne peut être utilisé comme nom de champ que si le champ définit aussi
primary_key=True
.
<nom_de_champ>
du modèle parent
<modèle>
entre en conflit avec le champ
<nom_de_champ>
du modèle parent
<modèle>
.
<nom_de_champ>
entre en conflit avec le champ
<nom_de_champ>
du modèle
<modèle>
.
<nom_de_champ>
a le nom de colonne
<nom_de_colonne>
qui est utilisé par un autre champ.
index_together
doit être une liste ou un tuple.
index_together
doivent être des listes ou des tuples.
unique_together
doit être une liste ou un tuple.
unique_together
doivent être des listes ou des tuples.
contrainte/index/index_together/unique_together
fait référence au champ inexistant
<nom_de_champ>
.
contrainte/index/index_together/unique_together
fait référence à un
<nom_de_champ>
de type
ManyToManyField
, mais ces champs ne sont pas pris en charge pour cette option.
ordering
doit être un tuple ou une liste (même si vous souhaitez trier sur un seul champ).
ordering
fait référence au champ, champ lié ou recherche inexistant
<nom_de_champ>
.
contrainte/index/index_together/unique_together
se réfèrent au champ
<nom_de_champ>
qui n’est pas local au modèle
<modèle>
.
<modèle>
contient des champs de modèle.
<champ>
. La longueur maximale est de
<longueur_maximum>
pour la base de données
<alias>
.
<champ>
. La longueur maximale est de
<longueur_maximum>
pour la base de données
<alias>
.
<modèle>.check()
est actuellement surchargée.
ordering
et
order_with_respect_to
ne peuvent pas être utilisés simultanément.
<fonction>
contient une référence différée à
<étiquette_app>.<modèle>
, mais l’application
<étiquette_app>
n’est pas installée ou ne fournit pas de modèle
<modèle>
.
<modèle>
ne peut pas commencer ni se terminer par un soulignement car cela entre en conflit avec la syntaxe de requête.
<modèle>
ne peut pas contenir de double soulignement car cela entre en conflit avec la syntaxe de requête.
<nom_de_propriété>
entre en conflit avec un accesseur de champ lié.
primary_key=True
.
<base
de
données>
ne prend pas en charge les contraintes de vérification.
db_table
<table_bd>
est utilisée par plusieurs modèles :
<liste
de
modèles>
.
<index>
n’est pas unique pour le modèle
<modèle>
.
<index>
n’est pas unique parmi les modèles :
<liste_modèles>
.
<contrainte>
n’est pas unique pour le modèle
<modèle>
.
<contrainte>
n’est pas unique parmi les modèles
<liste_modèles>
.
<index>
ne peut pas commencer par un soulignement, ni par un nombre.
<index>
ne peut pas dépasser
<max_length>
caractères.
db_table
<table_bd>
est utilisée par plusieurs modèles :
<liste
de
modèles>
.
<base
de
données>
ne prend pas en charge les contraintes d’unicité avec conditions.
<base
de
données>
ne prend pas en charge les index avec conditions.
<base
de
données>
ne prend pas en charge les contraintes d’unicité différables.
<base
de
données>
ne prend pas en charge les contraintes d’unicité avec des colonnes qui ne sont pas des clés.
<base
de
données>
ne prend pas en charge les index avec des colonnes qui ne sont pas des clés.
constraints
fait référence au champ joint
<nom_de_champ>
.
django.db.models.AutoField
.
<base
de
données>
ne prend pas en charge les index sur les expressions.
<base
de
données>
ne prend pas en charge les contraintes d’unicité avec les expressions.
<contrainte>
contient une expression
RawSQL()
et ne sera pas validée dans la méthode
full_clean()
du modèle.
<database>
ne prend pas en charge les commentaires sur les tables (
db_table_comment
).
Sécurité ¶
Les contrôles de sécurité ne rendent pas votre site sûr. Ils n’auditent pas votre code, ne font pas de détection d’intrusion ou quoi que ce soit d’autre de particulièrement complexe. Ils s’occupent plutôt d’une liste de contrôles automatisés détectant les problèmes les plus évidents qui peuvent vous aider à améliorer la sécurité d’un site.
Certains de ces contrôles ne sont pas forcément adéquats pour votre configuration de déploiement particulière. Par exemple, si vous avez délégué la redirection HTTP vers HTTPS à un répartiteur de charge, il serait gênant d’être constamment averti que le réglage
SECURE_SSL_REDIRECT
n’est pas actif. Utilisez
SILENCED_SYSTEM_CHECKS
pour réduire au silence les contrôles non nécessaires.
Les contrôles suivants sont exécutés si l’option
check
--deploy
est indiquée :
django.middleware.security.SecurityMiddleware
ne figure pas dans
MIDDLEWARE
ce qui rendra ineffectif les réglages
SECURE_HSTS_SECONDS
,
SECURE_CONTENT_TYPE_NOSNIFF
,
SECURE_REFERRER_POLICY
,
SECURE_CROSS_ORIGIN_OPENER_POLICY
et
SECURE_SSL_REDIRECT
.
django.middleware.clickjacking.XFrameOptionsMiddleware
ne figure pas dans
MIDDLEWARE
, ce qui fait que vos pages ne seront pas servies avec un en-tête
'x-frame-options'
. Sauf dans les cas où il existe une bonne raison pour que votre site apparaisse dans un cadre, il est recommandé d’activer cet en-tête pour contribuer à prévenir les attaques par détournement de clic.
django.middleware.csrf.CsrfViewMiddleware
ne figure pas dans
MIDDLEWARE
). L’activation de l’intergiciel est l’approche la plus sûre pour s’assurer qu’aucun trou ne subsiste dans cette protection.
SECURE_HSTS_SECONDS
. Si tout votre site est entièrement servi par SSL, il est possible d’envisager définir une valeur et d’activer
HSTS (HTTP Strict Transport Security)
. Mais prenez soin de lire premièrement la documentation ; l’activation précipitée de HSTS peut être la cause de problèmes sérieux et irréversibles.
SECURE_HSTS_INCLUDE_SUBDOMAINS
à
True
. Sans cela, votre site est potentiellement vulnérable à des attaques via une connexion non sécurisée à un sous-domaine. Ne choisissez la valeur
True
que si vous êtes sûr que tous les sous-domaines de votre domaine sont exclusivement servis par SSL.
SECURE_CONTENT_TYPE_NOSNIFF
n’est pas défini à
True
, ce qui fait que vos pages ne seront pas servies avec un en-tête
'X-Content-Type-Options:
nosniff'
. Vous devriez envisager d’activer cet en-tête pour empêcher les navigateurs d’identifier de manière incorrecte les types de contenu.
SECURE_BROWSER_XSS_FILTER
n’est pas défini à
True
, ce qui fait que vos pages ne seront pas servies avec un en-tête
'X-XSS-protection:
1;
mode=block'
. Vous devriez envisager d’activer cet en-tête pour activer le filtrage XSS des navigateurs et aider ainsi à prévenir les attaques XSS.
Ce contrôle a été supprimé dans Django 3.0 car l’en-tête
X-XSS-Protection
n’est plus pris en compte par les navigateurs modernes.
SECURE_SSL_REDIRECT
n’est pas défini à
True
. Sauf si votre site doit être accessible à la fois par des connexions SSL et non SSL, il est conseillé de soit définir ce réglage à
True
, soit de configurer un répartiteur de charge ou un serveur mandataire inverse pour rediriger toutes les connexions vers HTTPS.
SECRET_KEY
contient moins de 50 caractères, moins de 5 caractères différents ou est préfixée par
'django-insecure-'
, ce qui indique qu’elle a été générée automatiquement par Django. Veuillez générer une valeur longue et aléatoire, faute de quoi de nombreuses fonctionnalités de Django liées à la sécurité seront vulnérables aux attaques.
django.contrib.sessions
se trouve dans votre réglage
INSTALLED_APPS
mais vous n’avez pas défini
SESSION_COOKIE_SECURE
à
True
. L’utilisation d’un cookie de session sécurisé complique la tâche des renifleurs de trafic réseau quand ils essaient de s’immiscer dans les sessions des utilisateurs.
django.contrib.sessions.middleware.SessionMiddleware
figure dans
MIDDLEWARE
, mais vous n’avez pas défini
SESSION_COOKIE_SECURE
à
True
. L’utilisation d’un cookie de session sécurisé complique la tâche des renifleurs de trafic réseau quand ils essaient de s’immiscer dans les sessions des utilisateurs.
SESSION_COOKIE_SECURE
n’est pas défini à
True
. L’utilisation d’un cookie de session sécurisé complique la tâche des renifleurs de trafic réseau quand ils essaient de s’immiscer dans les sessions des utilisateurs.
django.contrib.sessions
se trouve dans votre réglage
INSTALLED_APPS
mais vous n’avez pas défini
SESSION_COOKIE_HTTPONLY
à
True
. L’utilisation d’un cookie de session
HttpOnly
complique la tâche des attaques par script inter-site quand elles essaient de s’immiscer dans les sessions des utilisateurs.
django.contrib.sessions.middleware.SessionMiddleware
figure dans
MIDDLEWARE
, mais vous n’avez pas défini
SESSION_COOKIE_HTTPONLY
à
True
. L’utilisation d’un cookie de session
HttpOnly
complique la tâche des attaques par script inter-site quand elles essaient de s’immiscer dans les sessions des utilisateurs.
SESSION_COOKIE_HTTPONLY
n’est pas défini à
True
. L’utilisation d’un cookie de session
HttpOnly
complique la tâche des attaques par script inter-site quand elles essaient de s’immiscer dans les sessions des utilisateurs.
CSRF_COOKIE_SECURE
n’est pas défini à
True
. L’utilisation d’un cookie CSRF sécurisé complique la tâche des renifleurs de trafic réseau quand ils essaient de voler le jeton CSRF.
CSRF_COOKIE_HTTPONLY
n’est pas défini à
True
. L’utilisation d’un cookie CSRF
HttpOnly
complique la tâche des attaques par script inter-site quand elles essaient de voler le jeton CSRF.
Ce contrôle est supprimé dans Django 1.11 car le réglage
CSRF_COOKIE_HTTPONLY
n’offre aucun bénéfice concret.
DEBUG
ne devrait pas être défini à
True
pour une application Django déployée.
django.middleware.clickjacking.XFrameOptionsMiddleware
figure dans
MIDDLEWARE
, mais
X_FRAME_OPTIONS
n’est pas défini à
'DENY'
. Sauf dans les cas où un site a une bonne raison de servir certaines de ses parties dans un cadre, vous devriez modifier ce réglage à
'DENY'
.
ALLOWED_HOSTS
ne peut pas être vide en déploiement.
SECURE_HSTS_PRELOAD
à
True
. Sans cela, votre site ne peut pas être proposé à la liste de préchargement des navigateurs.
SECURE_REFERRER_POLICY
. Sans cela, votre site n’enverra pas d’en-tête Referrer-Policy. Vous devriez envisager d’activer cet en-tête pour protéger la confidentialité des utilisateurs.
SECURE_REFERRER_POLICY
n’est pas valable.
SECURE_CROSS_ORIGIN_OPENER_POLICY
n’est pas valable.
SECRET_KEY_FALLBACKS[n]
contient moins de 50 caractères, moins de 5 caractères différents ou est préfixée par
'django-insecure-'
, ce qui indique qu’elle a été générée automatiquement par Django. Veuillez générer une valeur longue et aléatoire, faute de quoi de nombreuses fonctionnalités de Django liées à la sécurité seront vulnérables aux attaques.
Les contrôles suivants vérifient que les réglages liés à la sécurité sont correctement configurés :
DEFAULT_HASHING_ALGORITHM
doit contenir
'sha1'
ou
'sha256'
.
Ce contrôle est apparu dans Django 3.1 et 3.2
.
chemin.vers.vue
n’accepte pas le bon nombre d’arguments.
chemin.vers.vue
n’a pas pu être importée.
Signaux ¶
<gestionnaire>
est connecté au signal
<signal>
avec une référence différée vers l’expéditeur
<étiquette
app>.<modèle>
, mais
<étiquette
app>
n’est pas installé ou ne fournit pas le modèle
<modèle>
.
Gabarits ¶
Les contrôles suivants vérifient que le réglage
TEMPLATES
est configuré correctement :
'APP_DIRS':
True
figure dans votre réglage
TEMPLATES
mais
'loaders'
est aussi dans
OPTIONS
. Supprimez
APP_DIRS
ou l’option
'loaders'
.
string_if_invalid
dans
TEMPLATES
OPTIONS
doit être une chaîne, mais c’est actuellement :
{valeur}
(
{type}
).
<name>
est utilisé pour plusieurs modules de balises de gabarits:
<module
list>
.
Ce contrôle a été modifié en
templates.W003
dans Django 4.1.2
.
<name>
est utilisé pour plusieurs modules de balises de gabarits :
<module
list>
.
Traduction ¶
Les contrôles suivants sont effectués sur votre configuration de traduction :
LANGUAGE_CODE
contient une valeur non valide :
<valeur>
.
LANGUAGES
n’est pas valable :
<valeur>
.
LANGUAGES_BIDI
n’est pas valable :
<valeur>
.
LANGUAGE_CODE
n’est pas présente dans le réglage
LANGUAGES
.
URL ¶
Les contrôles suivants sont effectués sur votre configuration d’URL :
<pattern>
utilise
include()
avec une expression
route
se terminant par
$
. Enlevez le dollar de l’expression
route
pour éviter des problèmes lors de l’inclusion d’URL.
<pattern>
possède une expression
route
commençant par
/
. Enlevez cette barre oblique car elle n’est pas nécessaire. Si ce motif est référencé par un
include()
, vérifiez que le motif
include()
se termine par
/
.
<pattern>
possède un nom
name
contenant un
:
. Enlevez ces deux-points pour éviter des références d’espaces de noms ambigus.
<motif>
n’est pas valide. Vérifiez que
urlpatterns
est bien une liste d’instances
path()
ou
re_path()
.
<espace
de
nom>
n’est pas unique. Il est possible que certains URL de cet espace de noms ne puissent pas être résolus.
MEDIA_URL
/
STATIC_URL
doivent se terminer par une barre oblique.
handlerXXX
personnalisée
'chemin.vers.vue'
ne prend pas le nombre correct de paramètres (…).
handlerXXX
personnalisée
'chemin.vers.vue'
n’a pas pu être importée.
<motif>
possède un vue non valable, passez
<vue>.as_view()
au lieu de
<vue>
.
admin
¶
Les contrôles de l’interface d’administration sont tous effectués sous l’étiquette
admin
.
Les contrôles suivants sont effectués sur toute classe (ou sous-classe de)
ModelAdmin
qui est inscrite auprès du site d’administration :
raw_id_fields
doit être une liste ou un tuple.
raw_id_fields[n]
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
raw_id_fields[n]
doit être une clé étrangère ou un champ plusieurs-à-plusieurs.
fields
doit être une liste ou un tuple.
fieldsets
et
fields
sont tous deux spécifiés.
fields
contient des champs en double.
fieldsets
doit être une liste ou un tuple.
fieldsets[n]
doit être une liste ou un tuple.
fieldsets[n]
doit être de longueur 2.
fieldsets[n][1]
doit être un dictionnaire.
fieldsets[n][1]
doit contenir la clé
fields
.
fieldsets[n][1]
.
fields[n]/fieldsets[n][m]
cannot include the
ManyToManyField
<field
name>
, because that field manually specifies a
relationship model.
exclude
doit être une liste ou un tuple.
exclude
contient des champs en double.
form
doit hériter de
BaseModelForm
.
filter_vertical
doit être une liste ou un tuple.
filter_horizontal
doit être une liste ou un tuple.
filter_vertical[n]/filter_horizontall[n]
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
filter_vertical[n]/filter_horizontal[n]
doit être un champ plusieurs-à-plusieurs.
radio_fields
doit être un dictionnaire.
radio_fields
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
radio_fields
fait référence à
<nom_de_champ>
, qui n’est pas une instance de clé
ForeignKey
et n’a pas de définition
choices
.
radio_fields[<nom_de_champ>]
doit être soit
admin.HORIZONTAL
soit
admin.VERTICAL
.
view_on_site
doit être soit un objet exécutable, soit une valeur booléenne.
prepopulated_fields
doit être un dictionnaire.
prepopulated_fields
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
prepopulated_fields
fait référence à
<nom_de_champ>
, qui ne doit pas être un champ
DateTimeField
,
ForeignKey
,
OneToOneField
ni
ManyToManyField
.
prepopulated_fields[<nom_de_champ>]
doit être une liste ou un tuple.
prepopulated_fields
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
ordering
doit être une liste ou un tuple.
ordering
a le marqueur d’ordre aléatoire
?
, mais contient aussi d’autres champs.
ordering
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
readonly_fields
doit être une liste ou un tuple.
readonly_fields[n]
n’est pas appelable, un attribut de
<ModelAdmin
class>
, ou un attribut de
<model>
.
autocomplete_fields
doit être une liste ou un tuple.
autocomplete_fields[n]
fait référence à
<nom_de_champ>
, qui n’est pas un champ de
<modèle>
.
autocomplete_fields[n]
doit être une clé étrangère ou un champ plusieurs-à-plusieurs.
<modèle>
doit être inscrite pour être référencée par
<modeladmin>.autocomplete_fields
.
<modeladmin>
doit définir
search_fields
car il est référencé par
<autre_modeladmin>.autocomplete_fields
.
ModelAdmin
¶
Les contrôles suivants sont effectués sur toute classes (ou sous-classe de)
ModelAdmin
qui est enregistrée auprès du site d’administration:
save_as
doit être un booléen.
save_on_top
doit être un booléen.
inlines
doit être une liste ou un tuple.
<InlineModelAdmin
class>
doit hériter de
InlineModelAdmin
.
<InlineModelAdmin
class>
doit avoir un attribut
model
.
<InlineModelAdmin
class>.model
doit être un
Model
.
list_display
doit être une liste ou un tuple.
list_display[n]
fait référence à
<label>
, qui n’est pas un objet exécutable, un attribut de
<classe
ModelAdmin>
, ni un attribut ou une méthode de
<modèle>
.
list_display[n]
ne peut pas être un champ
ManyToManyField
.
list_display_links
doit être une liste, un tuple ou
None
.
list_display_links[n]
fait référence à
<label>
, qui n’est pas défini dans
list_display
.
list_filter
doit être une liste ou un tuple.
list_filter[n]
doit hériter de
ListFilter
.
list_filter[n]
ne doit pas hériter de
FieldListFilter
.
list_filter[n][1]
doit hériter de
FieldListFilter
.
list_filter[n]
fait référence à
<label>
, qui ne fait pas référence à un champ
Field
.
list_select_related
doit être une valeur booléenne, un tuple ou une liste.
list_per_page
doit être un nombre entier.
list_max_show_all
doit être un nombre entier.
list_editable
doit être une liste ou un tuple.
list_editable[n]
fait référence à
<label>
, qui n’est pas un champ de
<modèle>
.
list_editable[n]
fait référence à
<label>
, qui ne figure pas dans
list_display
.
list_editable[n]
ne peut pas être à la fois dans
list_editable
et dans
list_display_links
.
list_editable[n]
fait référence au tout premier champ dans
list_display
(
<label>
), qui ne peut pas utilisé tant que
list_display_links
n’est pas défini.
list_editable[n]
fait référence à
<nom_de_champ>
, qui n’est pas modifiable dans l’interface d’administration.
search_fields
doit être une liste ou un tuple.
date_hierarchy
fait référence à
<nom_de_champ>
, qui ne se réfère pas à un champ.
date_hierarchy
doit être un champ
DateField
ou
DateTimeField
.
<modeladmin>
doit définir une méthode
has_<foo>_permission()
pour l’action
<action>
.
__name__
des actions définies dans
<modeladmin>
doivent être uniques. Le nom
<nom>
n’est pas unique.
InlineModelAdmin
¶
Les contrôles suivants sont effectués sur chaque
InlineModelAdmin
qui est inscrit comme élément intégré dans une classe
ModelAdmin
.
<nom_de_champ>
, car il s’agit de la clé étrangère vers le modèle parent
<étiquette_application>.<modèle>
.
<modèle>
n’a pas de clé
ForeignKey
vers
<modèle
parent>
./
<modèle>
``
a
plus
d'une
clé
``ForeignKey
vers
<modèle
parent>
. Vous devez indiquer un attribut
fk_name
.
extra
doit être un nombre entier.
max_num
doit être un nombre entier.
min_num
doit être un nombre entier.
formset
doit hériter de
BaseModelFormSet
.
GenericInlineModelAdmin
¶
Les contrôles suivants sont effectués sur chaque
GenericInlineModelAdmin
qui est inscrit comme élément intégré dans une classe
ModelAdmin
.
'champ_ct'
fait référence à
<label>
, qui n’est pas un champ de
<modèle>
.
'champ_ct_fk'
fait référence à
<label>
, qui n’est pas un champ de
<modèle>
.
<modèle>
n’a pas de clé
GenericForeignKey
.
<modèle>
n’a pas de clé
GenericForeignKey
utilisant le champ de type de contenu
<nom_de_champ>
et le champ d’identifiant d’objet
<nom_de_champ>
.
AdminSite
¶
Les contrôles suivants sont effectués sur l’objet
AdminSite
par défaut :
django.contrib.contenttypes
doit être dans
INSTALLED_APPS
pour pouvoir utiliser l’application d’administration.
django.contrib.auth.context_processors.auth
doit être activé dans
DjangoTemplates
(
TEMPLATES
) si le moteur d’authentification par défaut est actif pour pouvoir utiliser l’application d’administration.
DjangoTemplates
doit être configurée dans
TEMPLATES
pour pouvoir utiliser l’application d’administration.
django.contrib.messages.context_processors.messages
doit être activé dans
DjangoTemplates
(
TEMPLATES
) pour pouvoir utiliser l’application d’administration.
django.contrib.auth
doit être dans
INSTALLED_APPS
pour pouvoir utiliser l’application d’administration.
django.contrib.messages
doit être dans
INSTALLED_APPS
pour pouvoir utiliser l’application d’administration.
django.contrib.auth.middleware.AuthenticationMiddleware
doit être dans
MIDDLEWARE
pour pouvoir utiliser l’application d’administration.
django.contrib.messages.middleware.MessageMiddleware
doit être dans
MIDDLEWARE
pour pouvoir utiliser l’application d’administration.
django.contrib.sessions.middleware.SessionMiddleware
doit être dans
MIDDLEWARE
pour pouvoir utiliser l’application d’administration.
django.template.context_processors.request
doit être activé dans
DjangoTemplates
(
TEMPLATES
) pour pouvoir utiliser le panneau latéral du site d’administration.
REQUIRED_FIELDS
doit être une liste ou un tuple.
USERNAME_FIELD
pour un modèle utilisateur personnalisé ne doit pas être inclus dans
REQUIRED_FIELDS
.
<champ>
doit être unique car il est désigné comme
USERNAME_FIELD
.
<champ>
est désigné comme
USERNAME_FIELD
, mais il n’est pas unique.
<nom_code>
entre en conflit avec une permission intégrée du modèle
<modèle>
.
<nom_code>
est à double pour le modèle
<modèle>
.
verbose_name
du modèle
<modèle>
ne doit pas dépasser 244 caractères pour que ses noms de permissions automatiques ne dépassent pas 255 caractères.
<nom>
du modèle
<modèle>
est plus longue que 255 caractères.
<modèle
utilisateur>.is_anonymous
doit être un attribut ou une propriété plutôt qu’une méthode. Il s’agit d’un problème de sécurité car avec une méthode, les utilisateurs anonymes seront considérés comme authentifiés !
<modèle
utilisateur>.is_authenticated
doit être un attribut ou une propriété plutôt qu’une méthode. Il s’agit d’un problème de sécurité car avec une méthode, les utilisateurs anonymes seront considérés comme authentifiés !
<modèle>
ne doit pas dépasser 93 caractères pour que ses noms de permissions automatiques ne dépassent pas 100 caractères.
<nom_code>
du modèle
<modèle>
est plus longue que 100 caractères.
contenttypes
¶
Les contrôles suivants sont effectués quand un modèle contient une clé
GenericForeignKey
ou une relation
GenericRelation
:
GenericForeignKey
fait référence au champ
<field>
qui n’existe pas.
GenericForeignKey
fait référence au champ
<field>
inexistant.
<champ>
n’est pas une clé
ForeignKey
.
<field>
n’est pas une
ForeignKey
vers
contenttypes.ContentType
.
postgres
¶
Les contrôles suivants s’appliquent aux champs de modèle
django.contrib.postgres
:
<champ>
doit être un objet exécutable plutôt qu’une instance afin qu’elle ne soit pas partagée entre toutes les instances de ce champ.
Ce contrôle a été modifié en
fields.E010
dans Django 3.1
.
sites
¶
Les contrôles suivants sont effectués sur chaque modèle utilisant un gestionnaire
CurrentSiteManager
:
CurrentSiteManager
n’a pas réussi à trouver un champ nommé
<nom_de_champ>
.
CurrentSiteManager
ne peut pas utiliser
<champ>
car ce n’est pas une clé étrangère ni un champ plusieurs-à-plusieurs.
Les contrôles suivants vérifient que
django.contrib.sites
est configuré correctement :
SITE_ID
doit être un nombre entier.
staticfiles
¶
Les contrôles suivants vérifient que
django.contrib.staticfiles
est configuré correctement :
STATICFILES_DIRS
n’est pas un tuple ni une liste.
STATICFILES_DIRS
ne doit pas contenir le réglage
STATIC_ROOT
.
<préfixe>
dans le réglage
STATICFILES_DIRS
ne peut pas se terminer par une barre oblique.
<répertoire>
dans le réglage
STATICFILES_DIRS
n’existe pas.
推荐文章