Voici une liste des réglages disponibles au sein de Django et leurs valeurs par défaut. Les réglages fournis par les applications contrib sont énumérés ci-dessous, suivi d’un index des réglages de base par sujet. Pour une introduction sur le sujet, consultez le guide thématique des réglages.
\nABSOLUTE_URL_OVERRIDESLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Un dictionnaire faisant correspondre des chaînes du style "étiquette_app.nom_modèle" à des fonctions qui acceptent un objet de modèle et renvoient son URL. C’est une façon d’insérer ou de surcharger les méthodes get_absolute_url() en fonction de l’installation. Par exemple :
ABSOLUTE_URL_OVERRIDES = {\n "blogs.blog": lambda o: "/blogs/%s/" % o.slug,\n "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),\n}\nLe nom de modèle utilisé dans ce réglage doit être tout en minuscules, quelle que soit la casse du nom de la classe modèle réelle.
\nADMINSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste de toutes les personnes qui reçoivent les notifications d’erreurs dans le code. Lorsque DEBUG=False et que AdminEmailHandler est configuré dans LOGGING (comportement par défaut), Django envoie un courriel à ces personnes contenant les détails des exceptions produites dans le cycle requête/réponse.
Chaque élément de la liste doit être une chaîne contenant une adresse électronique. Exemple :
\nADMINS = ["john@example.com", '"Ng, Mary" <mary@example.com>']\nTo safely build an address with a display name from variable content, see\nFormatting email addresses, which recommends using\nAddress over string formatting, but since this\nsetting requires a list of strings, wrap each Address in str(...).
ALLOWED_HOSTSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste de chaînes représentant des noms de domaine/d’hôte que ce site Django peut servir. C’est une mesure de sécurité pour empêcher les attaques d’en-tête Host HTTP, qui sont possibles même avec bien des configurations de serveur web apparemment sécurisées.
\nLes valeurs de cette liste peuvent être des noms complètement qualifiés (par ex. 'www.example.com'), auquel cas ils seront comparés exactement (insensible à la casse, port exclu) avec l’en-tête Host de la requête. Une valeur commençant par un point peut être utilisée comme métacaractère de sous-domaine : '.example.com' correspondra à example.com, www.example.com, et tout autre sous-domaine de example.com. Une valeur '*' correspond à tout ; dans ce cas, vous êtes responsable de fournir votre propre validation de l’en-tête Host (éventuellement dans un middleware ; dans ce cas, le middleware doit figurer en premier dans MIDDLEWARE).
Django permet également d’écrire un nom de domaine pleinement qualifié (FQDN) dans la liste. Certains navigateurs incluent un point terminal dans l’en-tête Host; Django l’enlève au moment de la validation d’hôte.
Si l’en-tête Host (ou X-Forwarded-Host quand USE_X_FORWARDED_HOST est actif) ne correspond à aucune valeur de cette liste, la méthode django.http.HttpRequest.get_host() lèvera SuspiciousOperation.
Lorsque DEBUG vaut True et que ALLOWED_HOSTS est vide, l’hôte est validé selon ['.localhost', '127.0.0.1', '[::1]'].
ALLOWED_HOSTS est aussi contrôlé lors de l’exécution des tests.
Cette validation ne s’applique qu’avec get_host() ; si votre code accède directement à l’en-tête Host dans request.META, vous outrepassez cette protection de sécurité.
APPEND_SLASHLien vers cette rubrique#Valeur par défaut : True
Si défini à True et que l’URL de la requête ne correspond à aucun des motifs de l’URLconf et que l’URL ne se termine pas par une barre oblique (slash), Django effectue une redirection HTTP vers la même URL additionnée d’une barre oblique finale. Notez que la redirection peut causer la perte d’éventuelles données envoyées avec une requête POST.
Le réglage APPEND_SLASH n’est utilisé que si CommonMiddleware est installé (voir Intergiciels (« Middleware »)). Voir aussi PREPEND_WWW.
CACHESLien vers cette rubrique#Valeur par défaut :
\n{\n "default": {\n "BACKEND": "django.core.cache.backends.locmem.LocMemCache",\n }\n}\nUn dictionnaire contenant les réglages de tous les caches à utiliser avec Django. C’est un dictionnaire imbriqué dont les contenus sont une correspondance entre les alias des caches et un dictionnaire contenant les options de chacun des caches.
\nLe réglage CACHES doit configurer un cache default (par défaut) ; il est possible d’ajouter autant d’autres caches que souhaité. Si vous utilisez un moteur de cache autre que le cache de mémoire locale ou que vous deviez définir plusieurs caches, d’autres options devront être ajoutées. Les options de cache suivantes sont disponibles.
BACKENDLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le moteur de cache à utiliser. Les moteurs de cache intégrés à Django sont :
\n'django.core.cache.backends.db.DatabaseCache'
'django.core.cache.backends.dummy.DummyCache'
'django.core.cache.backends.filebased.FileBasedCache'
'django.core.cache.backends.locmem.LocMemCache'
'django.core.cache.backends.memcached.PyMemcacheCache'
'django.core.cache.backends.memcached.PyLibMCCache'
'django.core.cache.backends.redis.RedisCache'
Vous pouvez utiliser un moteur de cache non livré avec Django en définissant BACKEND à un chemin complètement qualifié d’une classe de moteur de cache (par ex. monpaquet.moteurs.quelquechose.MonCache).
KEY_FUNCTIONLien vers cette rubrique#A string containing a dotted path to a function (or any callable) that defines\nhow to compose a key, prefix, and version into a final cache key. The default\nfunction converts the components to strings and joins them with colons, as\nshown in the cache documentation.
\nVous pouvez utiliser n’importe quelle fonction de clé, tant que la signature des paramètres est la même.
\nKEY_PREFIXLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Une chaîne qui sera automatiquement incluse (préfixée par défaut) à toutes les clés de cache utilisées par le serveur Django.
\nConsultez la documentation du cache pour plus d’informations.
\nLOCATIONLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
L’emplacement du cache. Cela peut être un répertoire pour un cache en système de fichiers, un hôte et un port pour le moteur memcache, ou un identifiant pour un cache en mémoire locale, par ex. :
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n }\n}\nOPTIONSLien vers cette rubrique#Valeur par défaut : None
Paramètres supplémentaires à transmettre au moteur de cache. Les paramètres disponibles varient en fonction du moteur de cache.
\nCertaines informations sur les paramètres disponibles peuvent être trouvées dans la documentation des paramètres de cache. Pour plus d’informations, consultez la documentation propre au module du moteur utilisé.
\nTIMEOUTLien vers cette rubrique#Valeur par défaut : 300
Le nombre de secondes avant qu’une entrée de cache soit considérée comme obsolète. Si la valeur de ce réglage est None, les contenus du cache n’expirent jamais. Une valeur de 0 provoque l’expiration immédiate des clés (effet équivalent à « ne pas mettre en cache »).
VERSIONLien vers cette rubrique#Valeur par défaut : 1
Le numéro de version par défaut des clés de cache générées par le serveur Django.
\nConsultez la documentation du cache pour plus d’informations.
\nCACHE_MIDDLEWARE_ALIASLien vers cette rubrique#Valeur par défaut : 'default'
La connexion de cache à utiliser pour l’intergiciel de cache.
\nCACHE_MIDDLEWARE_KEY_PREFIXLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Une chaîne qui servira de préfixe aux clés de cache générées par l’intergiciel de cache. Ce préfixe est combiné avec le réglage KEY_PREFIX, il ne le remplace pas.
CACHE_MIDDLEWARE_SECONDSLien vers cette rubrique#Valeur par défaut : 600
Le nombre entier de secondes correspondant à la durée par défaut de mise en cache d’une page pour l’intergiciel de cache.
\n\nCSRF_USE_SESSIONSLien vers cette rubrique#Valeur par défaut : False
Indique s’il faut stocker le jeton CSRF dans la session de l’utilisateur plutôt que dans un cookie. Cela nécessite la présence de django.contrib.sessions.
Le stockage du jeton CSRF dans un cookie (comportement par défaut de Django) est sûr, mais son stockage dans la session est une pratique courante dans d’autres cadriciels web et est donc parfois demandé par certains audits de sécurité.
\nComme les vues d’erreur par défaut exigent le jeton CSRF, SessionMiddleware doit apparaître dans MIDDLEWARE avant tout intergiciel pouvant générer une exception déclenchant une vue d’erreur (comme par exemple PermissionDenied) dans le cas où vous utilisez CSRF_USE_SESSIONS. Voir Ordre des intergiciels.
CSRF_FAILURE_VIEWLien vers cette rubrique#Valeur par défaut : 'django.views.csrf.csrf_failure'
Un chemin pointé vers la fonction Vue à utiliser lorsqu’une requête entrante est rejetée par la protection CSRF. La fonction doit avoir cette signature :
\ndef csrf_failure(request, reason=""): ...\noù reason est un bref message (à l’intention des développeurs ou de la journalisation, par pour les utilisateurs finaux) indiquant la raison du rejet de la requête. Elle devrait renvoyer une réponse HttpResponseForbidden.
django.views.csrf.csrf_failure() accepte un paramètre supplémentaire template_name qui vaut '403_csrf.html' par défaut. Si un gabarit de ce nom existe, il sera utilisé pour produire la page.
CSRF_HEADER_NAMELien vers cette rubrique#Valeur par défaut : 'HTTP_X_CSRFTOKEN'
Le nom de l’en-tête de requête utilisé pour l’authentification CSRF.
\nComme avec d’autres en-têtes HTTP dans request.META, le nom d’en-tête reçu du serveur est normalisé en convertissant tous les caractères en majuscules, remplaçant les tirets par des soulignements et en ajoutant un préfixe HTTP_ au nom. Par exemple, si un client envoie un en-tête 'X-XSRF-TOKEN', le réglage devrait être 'HTTP_X_XSRF_TOKEN'.
CSRF_TRUSTED_ORIGINSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste d’origines de confiance pour les types de requêtes non sûres (par ex. POST).
Pour les requêtes qui comprennent l’en-tête Origin, la protection CSRF de Django exige que cet en-tête corresponde à l’origine présente dans l’en-tête Host.
For a secure (determined by is_secure()) unsafe\nrequest that doesn’t include the Origin header, the request must include a\nReferer header that matches the origin in the Host header.
Ces contrôles empêchent par exemple une requête POST provenant de subdomain.example.com d’aboutir sur le site api.example.com. Si vous avez besoin de requêtes non sûres d’origine croisée, en continuant sur cet exemple, ajoutez 'https://subdomain.example.com' à cette liste (ou avec http://... si les requêtes proviennent d’une page non sécurisée).
Le réglage prend aussi en charge les sous-domaines, ce qui permet d’indiquer par exemple 'https://*.exemple.com' pour autoriser l’accès à tous les sous-domaines de exemple.com.
DATABASESLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Un dictionnaire contenant les réglages de toutes les bases de données à utiliser avec Django. C’est un dictionnaire imbriqué dont les contenus font correspondre l’alias de base de données avec un dictionnaire contenant les options de chacune des bases de données.
\nLe réglage DATABASES doit configurer une base de données default; il est possible de définir autant de bases de données que nécessaire.
Le fichier de réglages le plus simple possible est destiné à une configuration à base de données unique utilisant le moteur SQLite. Cela peut être configuré de cette façon :
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.sqlite3",\n "NAME": "mydatabase",\n }\n}\nLors de la connexion à d’autres moteurs de base de données, tels que MariaDB, MySQL, Oracle ou PostgreSQL, des paramètres de connexion supplémentaires sont requis. Voir le réglage ENGINE ci-dessous sur la façon de spécifier d’autres types de bases de données. Cet exemple vaut pour PostgreSQL :
DATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "NAME": "mydatabase",\n "USER": "mydatabaseuser",\n "PASSWORD": "mypassword",\n "HOST": "127.0.0.1",\n "PORT": "5432",\n }\n}\nLes options internes suivantes, qui peuvent être nécessaires pour des configurations plus complexes, sont disponibles :
\nATOMIC_REQUESTSLien vers cette rubrique#Valeur par défaut : False
Définissez ce réglage à True pour envelopper chaque vue dans une transaction sur cette base de données. Voir Couplage des transactions aux requêtes HTTP.
AUTOCOMMITLien vers cette rubrique#Valeur par défaut : True
Définissez ce réglage à False si vous souhaitez désactiver la gestion des transactions de Django et implémenter la vôtre.
ENGINELien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le moteur de base de données à utiliser. Les moteurs de base de données intégrés à Django sont :
\n'django.db.backends.postgresql'
'django.db.backends.mysql'
'django.db.backends.sqlite3'
'django.db.backends.oracle'
Vous pouvez utiliser un moteur de base de données non livré avec Django en définissant ENGINE à un chemin complètement qualifié d’une classe de moteur de base de données (par ex. monpaquet.moteurs.quelquechose).
HOSTLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
L’hôte à utiliser lors de la connexion à la base de données. Une chaîne vide signifie localhost. Non utilisé avec SQLite.
Si cette valeur commence par une barre oblique ('/') et que vous utilisez MySQL, MySQL se connectera par un connecteur Unix au connecteur indiqué. Par exemple :
"HOST": "/var/run/mysql"\nSi vous utilisez MySQL et que cette valeur ne commence pas par une barre oblique, Django part du principe que la valeur est un hôte.
\nSi vous utilisez PostgreSQL, par défaut (HOST vide), la connexion à la base de données se fait au travers de connecteurs Unix (lignes « local » dans pg_hba.conf). Si votre connecteur de domaine UNIX n’est pas à l’emplacement standard, utilisez la même valeur unix_socket_directory que celle de postgresql.conf. Si vous préférez vous connecter via des connecteurs TCP, définissez HOST à « localhost » ou « 127.0.0.1 » (lignes « host » dans pg_hba.conf). Sous Windows, vous devez toujours définir HOST, car les connecteurs de domaine Unix ne sont pas disponibles.
NAMELien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le nom de la base de données à utiliser. Pour SQLite, c’est le chemin complet vers le fichier de la base de données. Quand un chemin est indiqué, utilisez toujours des barres obliques vers l’avant, même sur Windows (par ex. C:/homes/user/mysite/sqlite3.db).
CONN_MAX_AGELien vers cette rubrique#Valeur par défaut : 0
La durée de vie d’une connexion de base de données, en nombre entier de secondes. Utilisez 0 pour fermer les connexions de base de données à la fin de chaque requête – comportement historique de Django – et None pour les connexions persistantes illimitées.
CONN_HEALTH_CHECKSLien vers cette rubrique#Valeur par défaut : False
Si défini à True, l’état des connexions persistantes aux bases de données sera contrôlé avant chaque réutilisation pour l’interrogation de la base de données. Si ce contrôle échoue, la connexion sera réétablie sans que la requête d’interrogation n’échoue dans le cas où la connexion n’est plus utilisable, mais que le serveur de base de données est prêt à accepter et servir de nouvelles connexions (par ex. après qu’un redémarrage de la base de données a fermé les connexions existantes).
OPTIONSLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Des paramètres supplémentaires à utiliser lors de la connexion à la base de données. Les paramètres disponibles varient en fonction du moteur de base de données.
\nCertaines informations sur les paramètres disponibles peuvent être trouvées dans la documentation des moteurs de base de données. Pour plus d’informations, consultez la documentation propre au module du moteur utilisé.
\nPASSWORDLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le mot de passe à utiliser lors de la connexion à la base de données. Non utilisé avec SQLite.
\nPORTLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le port à utiliser lors de la connexion à la base de données. Une chaîne vide signifie le port par défaut. Non utilisé avec SQLite.
\nTIME_ZONELien vers cette rubrique#Valeur par défaut : None
Une chaîne représentant le fuseau horaire de cette connexion de base de données ou None. Cette option interne au réglage DATABASES accepte les mêmes valeurs que le réglage général TIME_ZONE.
Lorsque setting:USE_TZ vaut True, la lecture de dates/heures de la base de données renvoie des dates/heures conscientes avec leur fuseau horaire défini à la valeur de cette option si différente de None, ou à UTC dans le cas contraire.
Lorsque USE_TZ vaut False, la définition de cette option produit une erreur.
Si le moteur de base de données ne gère pas les fuseaux horaires (par ex. SQLite, MySQL, Oracle), Django lit et écrit les dates/heures en heure locale en fonction de cette option quand elle est définie et en UTC si elle ne l’est pas.
\nLa modification du fuseau horaire de la connexion modifie la manière dont les dates/heures sont lues et écrites dans la base de données.
\nSi Django gère la base de données et que vous n’avez pas de forte raison de faire autrement, vous devriez laisser cette option non définie. Il est préférable de stocker les dates/heures en UTC car cela évite des dates/heures ambiguës ou inexistantes dans les passages heure d’été/heure d’hiver. De plus, la manipulation de dates/heures en UTC présente une arithmétique simple, sans avoir besoin de considérer les modifications potentielles de décalages lors d’une transition d’heure d’été/hiver.
Si vous vous connectez à une base de données externe qui stocke les dates/heures en temps locale plutôt qu’en UTC, vous devez définir cette option au fuseau horaire adéquat. De même, si Django gère la base de données mais que des systèmes externes se connectent à cette même base de données en espérant y trouver des dates/heures en temps local, vous devez définir cette option.
Si le moteur de base de données prend en charge les fuseaux horaires (par ex. PostgreSQL), le fuseau horaire de la connexion de base de données est défini à cette valeur.
\nMême s’il est rarement utile de définir l’option TIME_ZONE, il y a des situations ou cela devient nécessaire. En particulier, il est recommandé de correspondre au réglage général TIME_ZONE lorsqu’on manipule des requêtes brutes impliquant des fonctions date/heure comme date_trunc() or generate_series() dans PostgreSQL, particulièrement lors de génération de séries temporelles qui traversent des transitions d’heure d’été/hiver.
Cette valeur peut être modifiée à tout moment, la base de données se charge de la conversion des dates/heures vers le fuseau horaire configuré.
\nCependant, le revers de la médaille est que l’obtention de toutes les dates/heures en temps local fait appel à une arithmétique plus compliquée, vous devez tenir compte de possibles modifications de décalages lors de transitions d’heure d’été/hiver.
\nEnvisagez de convertir explicitement en temps local avec AT TIME ZONE dans les requêtes SQL brutes plutôt que de définir l’option TIME_ZONE.
DISABLE_SERVER_SIDE_CURSORSLien vers cette rubrique#Valeur par défaut : False
Définissez ce réglage à True si vous souhaitez désactiver l’utilisation de curseurs côté serveur avec QuerySet.iterator(). Transactions groupées et curseurs côté serveur explique le cas d’utilisation.
Ce réglage est spécifique à PostgreSQL.
\nUSERLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Le nom d’utilisateur à utiliser lors de la connexion à la base de données. Non utilisé avec SQLite.
\nTESTLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Un dictionnaire de réglages pour les bases de données de test ; pour plus de détails sur la création et l’utilisation de bases de données de test, voir La base de données de test.
\nVoici un exemple avec une configuration de base de données de test :
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.postgresql",\n "USER": "mydatabaseuser",\n "NAME": "mydatabase",\n "TEST": {\n "NAME": "mytestdatabase",\n },\n },\n}\nLes clés suivantes sont disponibles dans le dictionnaire TEST:
CHARSETLien vers cette rubrique#Valeur par défaut : None
Le codage de caractères utilisé pour créer la base de données de test. La valeur de cette chaîne est passée directement à la base de données, son format est donc dépendant du moteur.
\nPris en charge par les moteurs PostgreSQL (postgresql) et MySQL (mysql).
COLLATIONLien vers cette rubrique#Valeur par défaut : None
L’ordre de collation à utiliser lors de la création de la base de données de test. Cette value est directement transmise au moteur, son format est donc spécifique au moteur.
\nPris en charge uniquement pour le moteur mysql (consultez le manuel de MySQL pour plus de détails).
DEPENDENCIESLien vers cette rubrique#Valeur par défaut : ['default'], pour toutes les bases de données, excepté default qui n’a pas de dépendances.
Les dépendances d’ordre de création de la base de données. Consultez la documentation sur le contrôle de l’ordre de création des bases de données de test pour plus de détails.
\nMIGRATELien vers cette rubrique#Valeur par défaut : True
Si définie à False, les migrations ne s’exécuteront pas lors de la création de la base de données de test. C’est équivalent à définir None comme valeur dans MIGRATION_MODULES, mais pour toutes les applications.
MIRRORLien vers cette rubrique#Valeur par défaut : None
L’alias de base de données qui devra constituer le miroir de cette base de données durant les tests. Il y a dépendance des transactions, ce qui implique qu’il faut utiliser TransactionTestCase au lieu de TestCase.
Ce réglage existe pour permettre de tester des configurations primaire/réplique (aussi appelées maître-esclaves par certaines bases de données) de plusieurs bases de données. Consultez la documentation sur le test de configurations primaire/réplique pour plus de détails.
\nNAMELien vers cette rubrique#Valeur par défaut : None
Le nom de la base de données à utiliser lors du fonctionnement de la suite de tests.
\nSi la valeur par défaut (None) est utilisée avec le moteur de base de données SQLite, les tests utiliseront une base de données en mémoire vive. Pour tous les autres moteurs de base de données, la base de données de test sera nommée 'test_' + DATABASE_NAME.
TEMPLATELien vers cette rubrique#Ce réglage est spécifique à PostgreSQL.
\nLe nom d’un modèle (par ex. 'template0') à partir duquel la base de données de test est créée.
CREATE_DBLien vers cette rubrique#Valeur par défaut : True
Ce paramètre est spécifique à Oracle.
\nS’il est défini à False, l’espace de tables de test ne sera pas automatiquement créé au début des tests, ni supprimé à la fin.
CREATE_USERLien vers cette rubrique#Valeur par défaut : True
Ce paramètre est spécifique à Oracle.
\nSi défini à False, l’utilisateur test ne sera pas automatiquement créé au début des tests, ni supprimé à la fin.
USERLien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe nom d’utilisateur à utiliser lors de la connexion à la base de données Oracle durant les tests. Si non fourni, Django utilise 'test_' + USER.
PASSWORDLien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe mot de passe à utiliser lors de la connexion à la base de données Oracle durant les tests. Si non fourni, Django génère un mot de passe aléatoire.
\nORACLE_MANAGED_FILESLien vers cette rubrique#Valeur par défaut : False
Ce paramètre est spécifique à Oracle.
\nSi défini à True, des espaces de tables Oracle Managed Files (OMF) sont utilisées. DATAFILE et DATAFILE_TMP seront ignorés.
TBLSPACELien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe nom de l’espace de tables utilisé lors des tests. Si non fourni, Django utilise 'test_' + USER.
TBLSPACE_TMPLien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe nom de l’espace de tables temporaire utilisé lors des tests. Si non fourni, Django utilise 'test_' + USER + '_temp'.
DATAFILELien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe nom du fichier de données à utiliser pour TBLSPACE. Si non fourni, Django utilise TBLSPACE + '.dbf'.
DATAFILE_TMPLien vers cette rubrique#Valeur par défaut : None
Ce paramètre est spécifique à Oracle.
\nLe nom du fichier de données à utiliser pour TBLSPACE_TMP. Si non fourni, Django utilise TBLSPACE_TMP + '.dbf'.
DATAFILE_MAXSIZELien vers cette rubrique#Valeur par défaut : '500M'
Ce paramètre est spécifique à Oracle.
\nLa taille maximale que DATAFILE est autorisé à atteindre.
\nDATAFILE_TMP_MAXSIZELien vers cette rubrique#Valeur par défaut : '500M'
Ce paramètre est spécifique à Oracle.
\nLa taille maximale que DATAFILE_TMP est autorisé à atteindre.
\nDATAFILE_SIZELien vers cette rubrique#Valeur par défaut : '50M'
Ce paramètre est spécifique à Oracle.
\nLa taille initiale du fichier DATAFILE.
\nDATAFILE_TMP_SIZELien vers cette rubrique#Valeur par défaut : '50M'
Ce paramètre est spécifique à Oracle.
\nLa taille initiale du fichier DATAFILE_TMP.
\nDATAFILE_EXTSIZELien vers cette rubrique#Valeur par défaut : '25M'
Ce paramètre est spécifique à Oracle.
\nLa taille d’extension du fichier DATAFILE lorsque plus d’espace est nécessaire.
\nDATAFILE_TMP_EXTSIZELien vers cette rubrique#Valeur par défaut : '25M'
Ce paramètre est spécifique à Oracle.
\nLa taille d’extension du fichier DATAFILE_TMP lorsque plus d’espace est nécessaire.
\nDATA_UPLOAD_MAX_MEMORY_SIZELien vers cette rubrique#Valeur par défaut : 2621440 (c-à-d. 2.5 Mio).
La taille maximale en octets d’un corps de requête avant qu’il ne provoque une exception SuspiciousOperation (RequestDataTooBig). Le contrôle est effectué lors de l’accès à request.body ou à request.POST et est calculé par rapport à la taille totale de la requête sans les données d’envoi de fichiers (request.FILES). Vous pouvez le définir à None pour désactiver le contrôle. Les applications susceptibles de recevoir des envois de formulaires inhabituellement volumineux devraient ajuster ce réglage.
Under ASGI, the entire request may be spooled to disk before this limit is\nenforced. Therefore, it is strongly recommended to place additional protections\nin front of Django which limit the entire request payload.
\nLa quantité de données de requête est corrélée à la quantité de mémoire ou de stockage nécessaire pour traiter la requête et remplir les dictionnaires GET et POST. Les grosses requêtes pourraient être utilisées comme vecteur d’attaque par déni de service si elles n’étaient pas contrôlées. Comme les serveurs web n’effectuent en principe pas d’inspection approfondie des requêtes, il n’est pas possible de procéder à ce genre de contrôle à leur niveau.
\nVoir aussi FILE_UPLOAD_MAX_MEMORY_SIZE.
DATA_UPLOAD_MAX_NUMBER_FIELDSLien vers cette rubrique#Valeur par défaut : 1000
Le nombre maximum de paramètres pouvant être reçus via GET ou POST avant qu’une exception SuspiciousOperation (TooManyFields) soit générée. Vous pouvez le définir à None pour désactiver le contrôle. Les applications susceptibles de recevoir un nombre inhabituellement grand de champs de formulaire devraient ajuster ce réglage.
Le nombre de paramètres de requête est corrélé à la quantité de temps nécessaire pour traiter la requête et remplir les dictionnaires GET et POST. Les grosses requêtes pourraient être utilisées comme vecteur d’attaque par déni de service si elles n’étaient pas contrôlées. Comme les serveurs web n’effectuent en principe pas d’inspection approfondie des requêtes, il n’est pas possible de procéder à ce genre de contrôle à leur niveau.
\nDATA_UPLOAD_MAX_NUMBER_FILESLien vers cette rubrique#Valeur par défaut : 100
Le nombre maximum de fichiers pouvant être reçus via POST dans une requête codée en multipart/form-data avant qu’une exception SuspiciousOperation (TooManyFiles) soit générée. Vous pouvez le définir à None pour désactiver le contrôle. Les applications susceptibles de recevoir un nombre inhabituellement grand de champs fichiers devraient ajuster ce réglage.
Le nombre de fichiers acceptés est corrélé à la quantité de temps et de mémoire nécessaire pour traiter la requête. Les grosses requêtes pourraient être utilisées comme vecteur d’attaque par déni de service si elles n’étaient pas contrôlées. Comme les serveurs web n’effectuent en principe pas d’inspection approfondie des requêtes, il n’est pas possible de procéder à ce genre de contrôle à leur niveau.
\nDATABASE_ROUTERSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
La liste des routeurs utilisés pour déterminer à quelle base de données il faut accéder lors de l’exécution d’une requête de base de données.
\nConsultez la documentation sur le routage automatique des bases de données dans des configurations à plusieurs bases.
\nDATE_FORMATLien vers cette rubrique#Valeur par défaut : 'N j, Y' (ex . : Feb. 4, 2003)
Le format par défaut pour l’affichage des champs dates dans les différentes parties du système. Notez que le format induit par la locale a une priorité plus élevée et remplacera ce format. Voir les chaînes de format de date autorisées.
Voir aussi DATETIME_FORMAT, TIME_FORMAT et SHORT_DATE_FORMAT.
DATE_INPUT_FORMATSLien vers cette rubrique#Valeur par défaut :
\n[\n "%Y-%m-%d", # '2006-10-25'\n "%m/%d/%Y", # '10/25/2006'\n "%m/%d/%y", # '10/25/06'\n "%b %d %Y", # 'Oct 25 2006'\n "%b %d, %Y", # 'Oct 25, 2006'\n "%d %b %Y", # '25 Oct 2006'\n "%d %b, %Y", # '25 Oct, 2006'\n "%B %d %Y", # 'October 25 2006'\n "%B %d, %Y", # 'October 25, 2006'\n "%d %B %Y", # '25 October 2006'\n "%d %B, %Y", # '25 October, 2006'\n]\nUne liste de formats qui seront acceptés lors de la saisie de données dans un champ date. Les formats seront testés dans l’ordre et le premier correspondant sera utilisé. Notez que ces chaînes de format utilisent la syntaxe du module datetime de Python, et non pas celle des chaînes de format du filtre de gabarit date.
Le format induit par la locale a une priorité plus élevée et remplace ce séparateur.
\nVoir aussi DATETIME_INPUT_FORMATS et TIME_INPUT_FORMATS.
DATETIME_FORMATLien vers cette rubrique#Valeur par défaut : 'N j, Y, P' (ex. Feb. 4, 2003, 4 p.m.)
Le format par défaut pour l’affichage des champs dates/heures dans les différentes parties du système. Notez que le format induit par la locale a une priorité plus élevée et remplacera ce format. Voir les chaînes de format de date autorisées.
Voir aussi DATE_FORMAT, TIME_FORMAT et SHORT_DATETIME_FORMAT.
DATETIME_INPUT_FORMATSLien vers cette rubrique#Valeur par défaut :
\n[\n "%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59'\n "%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200'\n "%Y-%m-%d %H:%M", # '2006-10-25 14:30'\n "%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59'\n "%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200'\n "%m/%d/%Y %H:%M", # '10/25/2006 14:30'\n "%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59'\n "%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200'\n "%m/%d/%y %H:%M", # '10/25/06 14:30'\n]\nUne liste de formats qui seront acceptés lors de la saisie de données dans un champ date/heure. Les formats seront testés dans l’ordre et le premier correspondant sera utilisé. Notez que ces chaînes de format utilisent la syntaxe du module datetime de Python, et non pas celle des chaînes de format du filtre de gabarit date. Les formats contenant uniquement la date ne sont pas inclus car les champs date/heure essaient automatiquement les formats DATE_INPUT_FORMATS en dernier recours.
Le format induit par la locale a une priorité plus élevée et remplace ce séparateur.
\nVoir aussi DATE_INPUT_FORMATS et TIME_INPUT_FORMATS.
DEBUGLien vers cette rubrique#Valeur par défaut : False
Une valeur booléenne qui active ou désactive le mode de débogage.
\nNe déployez jamais de site en production avec le réglage DEBUG activé.
L’une des fonctionnalités principales du mode de débogage est l’affichage de pages d’erreur détaillées. Si votre application lève une exception quand DEBUG vaut True, Django affiche une trace détaillée, y compris de nombreuses métadonnées au sujet de votre environnement, comme par exemple la liste complète des réglages Django en vigueur (tirés de settings.py).
Comme mesure de sécurité, Django n’affiche pas les réglages pouvant comporter des données sensibles, comme SECRET_KEY. Plus précisément, il exclut tout réglage dont le nom contient l’un des éléments suivants :
'API'
'KEY'
'PASS'
'SECRET'
'SIGNATURE'
'TOKEN'
Notez qu’il s’agit de correspondances partielles. 'PASS' va aussi intercepter PASSWORD, comme 'TOKEN' interceptera TOKENIZED et ainsi de suite.
Toutefois, notez qu’il y aura toujours des parties de l’affichage de débogage qui contiennent des éléments inappropriés pour le tout public. Des chemins de fichiers, des options de configuration et d’autres choses semblables peuvent tous donner à des attaquants des informations supplémentaires au sujet de votre serveur.
\nIl est aussi important de se rappeler que lorsque un site fonctionne en mode DEBUG, Django mémorise chaque requête SQL qu’il exécute. C’est utile lors de séances de débogage, mais cela va assez rapidement consommer beaucoup de mémoire sur un serveur de production.
Enfin, si DEBUG vaut False, vous devez également définir correctement le réglage ALLOWED_HOSTS. Sans cela, toutes les requêtes renverront l’erreur « Bad Request (400) ».
DEBUG_PROPAGATE_EXCEPTIONSLien vers cette rubrique#Valeur par défaut : False
Si défini à True, le traitement des exceptions par Django des fonctions de vue (handler500 ou la vue de débogage si DEBUG vaut True) ainsi que la journalisation des réponses 500 (django.request) sont omis et les exceptions sont propagées vers le haut.
Cela peut être utile dans certaines configurations de test. Ce ne devrait pas être utilisé pour un site en production sauf dans le cas où vous aimeriez que le serveur web génère lui-même les réponses « Internal Server Error » à la place de Django. Dans ce cas, veillez à ce que le serveur n’affiche pas la trace de débogage ou d’autres informations sensibles dans la réponse.
\nDECIMAL_SEPARATORLien vers cette rubrique#Valeur par défaut : '.' (point)
Séparateur décimal par défaut utilisé lors du formatage des nombres à virgule.
\nNotez que le format induit par la locale a une priorité plus élevée et sera donc utilisé à la place.
\nVoir aussi NUMBER_GROUPING, THOUSAND_SEPARATOR et USE_THOUSAND_SEPARATOR.
DEFAULT_AUTO_FIELDLien vers cette rubrique#Valeur par défaut : 'django.db.models.BigAutoField'
Type de champ clé primaire à utiliser par défaut pour les modèles n’ayant pas de champ avec primary_key=True.
DEFAULT_CHARSETLien vers cette rubrique#Valeur par défaut : 'utf-8'
Codage de caractères par défaut utilisé pour tous les objets HttpResponse si un type MIME n’est pas manuellement indiqué. Utilisé pour construire l’en-tête Content-Type.
DEFAULT_EXCEPTION_REPORTERLien vers cette rubrique#Valeur par défaut : 'django.views.debug.ExceptionReporter'
Classe de rapports d’exception utilisée par défaut si aucune n’a été attribuée à l’instance HttpRequest. Voir Rapports d’erreur personnalisés.
DEFAULT_EXCEPTION_REPORTER_FILTERLien vers cette rubrique#Valeur par défaut : 'django.views.debug.SafeExceptionReporterFilter'
Classe de filtre de rapports d’exception utilisée par défaut si aucune n’a été attribuée à l’instance HttpRequest. Voir Filtrage des rapports d’erreur.
DEFAULT_FROM_EMAILLien vers cette rubrique#Valeur par défaut : 'webmaster@localhost'
Adresse de courriel par défaut pour l’envoi de correspondance automatisée en provenance du gestionnaire du site. Cette adresse est utilisée dans l’en-tête From: des courriels sortants et accepte tout format valide pour le protocole d’envoi de courriel configuré.
Cela ne concerne pas les messages d’erreur envoyés aux ADMINS et aux MANAGERS. Voir SERVER_EMAIL pour ces cas de figure.
To build an address with a display name from variable content, see\nFormatting email addresses.
\nDEFAULT_INDEX_TABLESPACELien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Espace de tables utilisé par défaut pour les index sur les champs qui n’en indiquent pas, si le moteur les prend en charge (voir Espaces de tables).
\nDEFAULT_TABLESPACELien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Espace de tables utilisé par défaut pour les modèles qui n’en indiquent pas, si le moteur les prend en charge (voir Espaces de tables).
\nDISALLOWED_USER_AGENTSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Liste d’objets d’expressions régulières compilées représentant des chaînes d’agent utilisateur (User-Agent) qui ne sont globalement pas autorisés à visiter le site. Utile pour les robots ou les collecteurs malveillants. Ce réglage n’est utilisé que si CommonMiddleware est installé (voir Intergiciels (« Middleware »)).
EMAIL_BACKENDLien vers cette rubrique#Default: 'django.core.mail.backends.smtp.EmailBackend'
Le moteur à utiliser pour envoyer des courriels. Consultez Moteurs de messagerie pour obtenir la liste des moteurs disponibles.
\n\nEMAIL_FILE_PATHLien vers cette rubrique#Valeur par défaut : non définie
\nLe répertoire utilisé par le moteur de messagerie file pour stocker les fichiers qu’il produit.
\n\nEMAIL_HOSTLien vers cette rubrique#Valeur par défaut : 'localhost'
L’hôte à utiliser pour envoyer des courriels.
\nVoir aussi EMAIL_PORT.
EMAIL_HOST_PASSWORDLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Mot de passe à utiliser pour le serveur SMTP défini dans EMAIL_HOST. Ce réglage est utilisé conjointement avec EMAIL_HOST_USER lors de l’authentification au serveur SMTP. Si l’un de ces réglages est vide, Django ne tente pas de s’authentifier.
Voir aussi EMAIL_HOST_USER.
EMAIL_HOST_USERLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Nom d’utilisateur à utiliser pour le serveur SMTP défini dans EMAIL_HOST. S’il est vide, Django ne tente pas de s’authentifier.
Voir aussi EMAIL_HOST_PASSWORD.
EMAIL_PORTLien vers cette rubrique#Valeur par défaut : 25
Port à utiliser pour le serveur SMTP défini dans EMAIL_HOST.
EMAIL_SUBJECT_PREFIXLien vers cette rubrique#Valeur par défaut : '[Django] '
Préfixe de la ligne du sujet dans les messages électroniques envoyés avec django.core.mail.mail_admins ou django.core.mail.mail_managers. Une espace finale est probablement adéquate.
EMAIL_USE_LOCALTIMELien vers cette rubrique#Valeur par défaut : False
Indique s’il faut définir l’en-tête SMTP Date des courriels envoyés dans le fuseau horaire local (True) ou en UTC (False).
EMAIL_USE_TLSLien vers cette rubrique#Valeur par défaut : False
Indique si une connexion TLS (sécurisée) doit être utilisée pour le dialogue avec le serveur SMTP. Ceci s’applique aux connexions TLS explicites, généralement sur le port 587. Si vous obtenez des connexions qui se bloquent, consultez le réglage TLS implicite EMAIL_USE_SSL.
EMAIL_USE_SSLLien vers cette rubrique#Valeur par défaut : False
Indique si une connexion TLS implicite (sécurisée) doit être utilisée pour le dialogue avec le serveur SMTP. Dans la plupart de documentations de messagerie électronique, ce type de connexion TLS s’appelle SSL. C’est généralement le port 465 qui est utilisé. Si vous rencontrez des problèmes, consultez le réglage TLS explicite EMAIL_USE_TLS.
Notez que EMAIL_USE_TLS/EMAIL_USE_SSL sont mutuellement exclusifs, un seul d’entre eux peut donc être défini à True.
EMAIL_SSL_CERTFILELien vers cette rubrique#Valeur par défaut : None
Si EMAIL_USE_SSL ou EMAIL_USE_TLS valent True et que la connexion sécurisée au serveur SMTP nécessite une authentification du client, utilisez ce réglage pour indiquer le chemin vers un fichier de chaîne de certificat de type PEM, qui doit être utilisé conjointement avec EMAIL_SSL_KEYFILE.
EMAIL_SSL_CERTFILE ne doit pas être utilisé avec un certificat de serveur autosigné ou un certificat d’une autorité de certification (CA) privée. Dans de tels cas, le certificat du serveur (ou le certificat racine du CA privé) doit être installé dans le paquet des CA du système. Cela peut se faire en suivant les instructions spécifiques à votre plateforme pour installer un CA de certificat racine, ou en utilisant les variables d’environnement d’OpenSSL SSL_CERT_FILE ou SSL_CERT_DIR pour indiquer un paquet de certificats personnalisé (si la modification au niveau système n’est pas possible ou pas souhaitée).
For more complex scenarios, the SMTP EmailBackend can be subclassed to add root certificates to its\nssl_context using\nssl.SSLContext.load_verify_locations().
EMAIL_SSL_KEYFILELien vers cette rubrique#Valeur par défaut : None
Si EMAIL_USE_SSL ou EMAIL_USE_TLS valent True, vous pouvez définir de manière facultative le chemin vers un fichier de clé privée au format PEM pour l’authentification cliente de la connexion SSL, conjointement avec EMAIL_SSL_CERTFILE.
Notez que la définition de EMAIL_SSL_CERTFILE et de EMAIL_SSL_KEYFILE n’amène à aucune vérification de certificat. Ces valeurs sont transmises à la connexion SSL sous-jacente. Veuillez vous référer à la documentation de la fonction ssl.SSLContext.wrap_socket() de Python pour des détails sur la façon dont les fichiers de chaîne de certificat et de clé privée sont traités.
EMAIL_TIMEOUTLien vers cette rubrique#Valeur par défaut : None
Définit un délai d’expiration en secondes pour des opérations bloquantes telles que la tentative de connexion.
\n\nFILE_UPLOAD_HANDLERSLien vers cette rubrique#Valeur par défaut :
\n[\n "django.core.files.uploadhandler.MemoryFileUploadHandler",\n "django.core.files.uploadhandler.TemporaryFileUploadHandler",\n]\nUne liste de gestionnaires à utiliser pour le téléversement de fichiers. Ce réglage permet de personnaliser complètement (même remplacer) le processus de gestion des téléversements par Django.
\nSee Gestionnaires de téléversement for details.
\nFILE_UPLOAD_MAX_MEMORY_SIZELien vers cette rubrique#Valeur par défaut : 2621440 (c-à-d. 2.5 Mio).
The maximum size (in bytes) that an upload will be before it gets streamed to\nthe file system. See Gestionnaires de téléversement for details.
\nVoir aussi DATA_UPLOAD_MAX_MEMORY_SIZE.
FILE_UPLOAD_DIRECTORY_PERMISSIONSLien vers cette rubrique#Valeur par défaut : None
Le mode numérique à appliquer aux répertoires créés durant le processus de téléversement de fichiers.
\nCe réglage détermine également les permissions par défaut pour les répertoires de recueil des fichiers statiques lors de l’utilisation de la commande d’administration collectstatic. Voir collectstatic pour des détails sur la façon de le redéfinir.
Cette valeur reflète la fonctionnalité et les restrictions du réglage FILE_UPLOAD_PERMISSIONS.
FILE_UPLOAD_PERMISSIONSLien vers cette rubrique#Valeur par défaut : 0o644
Le mode numérique (ex : 0o644) des permissions pour les nouveaux fichiers téléversés. Pour plus d’informations sur la signification des ces modes, consultez la documentation de os.chmod().
Si ce réglage vaut None, vous obtiendrez un comportement dépendant du système d’exploitation. Sur la plupart des plates-formes, les fichiers temporaires obtiennent un mode 0o600 et les fichiers enregistrés à partir de la mémoire sont enregistrés avec le masque « umask » standard du système.
Pour des raisons de sécurité, ces permissions ne sont pas appliquées aux fichiers temporaires qui sont stockés dans FILE_UPLOAD_TEMP_DIR.
Ce réglage détermine également les permissions par défaut pour les fichiers statiques recueillis par la commande d’administration collectstatic. Voir collectstatic pour des détails sur la façon de le redéfinir.
FILE_UPLOAD_TEMP_DIRLien vers cette rubrique#Valeur par défaut : None
Le répertoire dans lequel stocker temporairement les données (typiquement pour les fichiers plus grands que FILE_UPLOAD_MAX_MEMORY_SIZE) lors des téléversements de fichiers. Avec la valeur None, Django utilise le répertoire temporaire standard du système d’exploitation. Par exemple, il s’agit de /tmp sur les systèmes d’exploitation de type Unix.
See Gestionnaires de téléversement for details.
\nFIRST_DAY_OF_WEEKLien vers cette rubrique#Valeur par défaut : 0 (dimanche)
Un nombre représentant le premier jour de la semaine. C’est particulièrement utile lors de l’affichage d’un calendrier. Cette valeur n’est utilisée que si les formats internationaux ne sont pas en vigueur ou si un format n’est pas trouvé pour la langue actuelle.
\nLa valeur est un entier de 0 à 6, où 0 signifie dimanche, 1 signifie lundi, etc.
\nFIXTURE_DIRSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Liste de répertoires dans lesquels des fichiers d’instantanés sont recherchés, en plus du répertoire fixtures de chaque application, dans l’ordre de recherche.
Notez que ces chemins doivent utiliser les barres obliques de style Unix, même avec Windows.
\nVoir Ajout de données par des instantanés et Chargement des instantanés.
\nFORCE_SCRIPT_NAMELien vers cette rubrique#Valeur par défaut : None
Si différent de None, ce réglage est utilisé comme valeur de la variable d’environnement SCRIPT_NAME dans toute requête HTTP. Il peut être utilisé pour surcharger la valeur de SCRIPT_NAME fournie par le serveur, qui peut être une version réécrite de la valeur préférée ou carrément absente. Il est aussi utilisé par django.setup() pour définir le préfixe de script du résolveur d’URL en dehors du cycle requête/réponse (par ex. dans les commandes d’administration et les scripts autonomes) pour générer des URL correctes lorsque FORCE_SCRIPT_NAME possède une valeur.
FORM_RENDERERLien vers cette rubrique#Valeur par défaut : 'django.forms.renderers.DjangoTemplates'
La classe qui produit les formulaires et composants de formulaires HTML. Elle doit implémenter l’API de rendu de bas niveau. Les producteurs de formulaires inclus sont :
\n\nFORMAT_MODULE_PATHLien vers cette rubrique#Valeur par défaut : None
Un chemin Python complet vers un paquet Python contenant des définitions de formats personnalisées pour les locales du projet. Si différent de None, Django cherche un fichier formats.py dans le répertoire dont le nom correspond à la locale en cours et utilise les formats définis dans ce fichier.
Le nom du répertoire contenant les définitions de format doit respecter le format de nommage avec la notation de nom de locale. Par exemple, de, pt_BR, es_AR, etc.
Par exemple, si FORMAT_MODULE_PATH est défini à mysite.formats et que la langue actuelle est en (anglais), Django s’attend à une arborescence de répertoires comme celle-ci :
mysite/\n formats/\n __init__.py\n en/\n __init__.py\n formats.py\nVous pouvez aussi définir ce réglage à une liste de chemins Python, par exemple :
\nFORMAT_MODULE_PATH = [\n "mysite.formats",\n "some_app.formats",\n]\nLorsque Django recherche un certain format, il va parcourir tous les chemins Python indiqués jusqu’à ce qu’il trouve un module qui définit réellement le format recherché. Cela signifie que les formats définis dans les premiers paquets de la liste ont la priorité sur les formats des paquets suivants.
\nLes formats disponibles sont :
\n\nIGNORABLE_404_URLSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
List of compiled regular expression objects describing URLs that should be\nignored when reporting HTTP 404 errors via email (see\nGestion du signalement des erreurs). Regular expressions are matched against\nrequest’s full paths, as returned by\nget_full_path() (including any query strings).\nUse this if your site does not provide a commonly requested file such as\nfavicon.ico or robots.txt.
Ce n’est utilisé que si BrokenLinkEmailsMiddleware est activé (voir Intergiciels (« Middleware »)).
INSTALLED_APPSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste de chaînes désignant toutes les applications activées dans cette installation de Django. Chaque chaîne doit correspondre à un chemin pointé Python vers :
\nune classe de configuration d’application (de préférence), ou
un paquet contenant une application.
En savoir plus sur les configurations d’applications.
\n\n\nLorsque plusieurs applications fournissent différentes versions de la même ressource (gabarit, fichier statique, commande d’administration, traduction), l’application apparaissant en premier dans INSTALLED_APPS a la priorité.
INTERNAL_IPSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste d’adresses IP, sous forme de chaînes, dont les requêtes :
\nPermettent au processeur de contexte debug() d’ajouter quelques variables au contexte du gabarit.
Peuvent utiliser les signets dynamiques de admindocs même si l’utilisateur n’est pas connecté en tant qu’administrateur (staff).
Sont marquées comme « internes » (et non pas « EXTERNAL ») dans les courriels envoyés par AdminEmailHandler.
LANGUAGE_CODELien vers cette rubrique#Valeur par défaut : 'en-us'
Une chaîne représentant le code de langue de cette installation. Elle doit respecter le format de langue standard. Par exemple, l’anglais américain est "en-us". Voir aussi la liste des identifiants de langue et Internationalisation et régionalisation.
Ce réglage sert à trois fins :
\nSi l’intergiciel de localisation n’est pas actif, il décide quelle traduction est utilisée pour tous les utilisateurs.
Si l’intergiciel de localisation est actif, il fournit une langue par défaut dans le cas où la langue préférée de l’utilisateur ne peut être déterminée ou n’est pas prise en charge par le site web. Il fournit également la traduction par défaut lorsqu’une traduction d’une chaîne donnée n’existe pas dans la langue préférée de l’utilisateur.
Si la régionalisation est explicitement désactivée via le filtre unlocalize ou la balise {% localize off %}, il indique quels formats de régionalisation de base seront appliqués. Voir contrôle de la régionalisation dans les gabarits pour plus de détails.
Voir Processus de découverte de la préférence de langue par Django pour plus de détails.
\nLANGUAGESLien vers cette rubrique#Valeur par défaut : une liste des langues disponibles. Cette liste augmentant continuellement, nous évitons de la reproduire ici, car elle deviendrait vite obsolète. Vous pouvez consultez la liste des langues disposant d’une traduction en examinant le fichier django/conf/global_settings.py.
\nLa liste est formée de listes binaires dans le format (code de langue, nom_de_langue), par exemple ('ja', 'Japanese'). Cette liste définit les langues disponibles dans la sélection de langues. Voir Internationalisation et régionalisation.
Généralement, la valeur par défaut convient bien. Ne définissez ce réglage que si vous souhaitez restreindre la sélection de langues à un sous-ensemble des langues fournies par Django.
\nSi vous personnalisez le réglage LANGUAGES, vous pouvez marquer les noms des langues en tant que chaînes à traduire en utilisant la fonction gettext_lazy().
Voici un exemple de fichier de réglages :
\nfrom django.utils.translation import gettext_lazy as _\n\nLANGUAGES = [\n ("de", _("German")),\n ("en", _("English")),\n]\nLANGUAGES_BIDILien vers cette rubrique#Valeur par défaut : une liste de codes de langues qui s’écrivent de droite à gauche. Vous pouvez consultez la liste de ces langues en examinant le fichier django/conf/global_settings.py.
\nLa liste contient des codes de langue pour les langues qui s’écrivent de droite à gauche.
\nGénéralement, la valeur par défaut convient bien. Ne définissez ce réglage que si vous souhaitez restreindre la sélection de langues à un sous-ensemble des langues fournies par Django. Si vous définissez un réglage LANGUAGES personnalisé, la liste des langues bidirectionnelles peut contenir des codes de langue non activés pour un site particulier.
LOCALE_PATHSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste de répertoires dans lesquels Django cherche les fichiers de traduction. Voir Processus de découverte des traductions par Django.
\nExemple :
\nLOCALE_PATHS = [\n "/home/www/project/common_files/locale",\n "/var/local/translations/locale",\n]\nDjango cherche dans chacun de ces chemins des répertoires <code_locale>/LC_MESSAGES contenant eux-mêmes les fichiers de traduction réels.
LOGGINGLien vers cette rubrique#Valeur par défaut : un dictionnaire de configuration de la journalisation.
\nUne structure de données contenant les informations de configuration. Lorsqu’il n’est pas vide, le contenu de cette structure de données est transmis comme paramètre à la méthode de configuration indiquée par LOGGING_CONFIG.
Entre autres choses, la configuration par défaut de la journalisation transmet les erreurs de serveur HTTP 500 à un gestionnaire de journal de type courriel lorsque DEBUG vaut False. Voir aussi Configuration de la journalisation.
Vous pouvez voir la configuration par défaut de journalisation en regardant dans django/utils/log.py.
\nLOGGING_CONFIGLien vers cette rubrique#Valeur par défaut : 'logging.config.dictConfig'
Un chemin vers un exécutable qui sera utilisé pour configurer la journalisation du projet Django. Par défaut, il contient une instance de la méthode de configuration dictConfig de Python.
\nSi vous définissez LOGGING_CONFIG à None, le processus de configuration de la journalisation sera court-circuité.
MAILERSLien vers cette rubrique#Valeur par défaut : non définie
\nA dictionary containing the settings for all email backends to be used with\nDjango. It is a nested dictionary that maps backend aliases to dictionaries\ncontaining each mailer’s backend import path and configuration options.
\nExemple :
\nMAILERS = {\n "default": {\n "BACKEND": "django.core.mail.backends.smtp.EmailBackend",\n "OPTIONS": {\n "host": "smtp.example.net",\n },\n },\n "newsletters": {\n "BACKEND": "django.core.mail.backends.smtp.EmailBackend",\n "OPTIONS": {\n "host": "smtp.bulk-email-service.example.com",\n "username": os.environ["BULK_EMAIL_SERVICE_ACCOUNT_ID"],\n "password": os.environ["BULK_EMAIL_SERVICE_API_KEY"],\n "use_tls": True,\n },\n },\n}\nIf you plan to send email through Django, configuring at least a "default"\nmailer is recommended. Any number of additional mailers may also be specified.\nDepending on which backend is used, other options may be required.
Setting MAILERS to an empty dictionary ({}) disables email sending and\nany attempt to send mail will raise MailerDoesNotExist.
See Configuring email for more information.
\n\nBACKENDLien vers cette rubrique#Default: "django.core.mail.backends.smtp.EmailBackend"
The Python import path to the email backend class. If "BACKEND" is omitted,\nDjango’s Le moteur SMTP is used.
See Moteurs de messagerie for a list of Django’s built-in backends and\npointers to community-maintained options.
\nOPTIONSLien vers cette rubrique#Valeur par défaut : {}
Configuration parameters to pass to the email backend. The available and\nrequired options vary depending on the backend.
\nMANAGERSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste dans le même format que ADMINS qui détermine qui doit recevoir les notifications de liens brisés lorsque BrokenLinkEmailsMiddleware est activé.
MEDIA_ROOTLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
Chemin absolu de système de fichiers pointant vers le répertoire qui contiendra les fichiers téléversés par les utilisateurs.
\nExemple : "/var/www/example.com/media/"
Voir aussi MEDIA_URL.
MEDIA_URLLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
URL qui gère les fichiers médias servis à partir de MEDIA_ROOT, utilisée pour la gestion des fichiers stockés. Elle doit se terminer par une barre oblique si elle ne contient pas de valeur vide. Il sera nécessaire de configurer ces fichiers afin d’être servis aussi bien en environnement de développement que de production.
Si vous souhaitez utiliser {{ MEDIA_URL }} dans vos gabarits, ajoutez 'django.template.context_processors.media' dans l’option 'context_processors' de TEMPLATES.
Exemple : "https://media.example.com/"
MIDDLEWARELien vers cette rubrique#Valeur par défaut : None
Une liste d’intergiciels à utiliser. Voir Intergiciels (« Middleware »).
\nMIGRATION_MODULESLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Un dictionnaire indiquant le paquet où les modules de migration peuvent être trouvés pour chaque application. La valeur par défaut de ce réglage est un dictionnaire vide, mais le nom de paquet par défaut pour les modules de migration est migrations.
Exemple :
\n{"blog": "blog.db_migrations"}\nDans ce cas, les migrations concernant l’application blog seront contenues dans le paquet blog.db_migrations.
Si vous fournissez le paramètre app_label, makemigrations crée automatiquement le paquet s’il n’existe pas déjà.
Lorsque vous fournissez None comme valeur pour une application, Django considère l’application comme sans migrations, sans prendre en compte un éventuel sous-module migrations existant. Ceci peut être utilisé, par exemple, dans un fichier de réglages de test pour sauter les migrations durant les tests (les tables seront quand même créées pour les modèles des applications). Pour désactiver les migrations de toutes les applications pendant les tests, vous pouvez définir le réglage MIGRATE à False. Si MIGRATION_MODULES est utilisé dans les réglages généraux du projet, pensez à utiliser l’option migrate --run-syncdb si vous souhaitez créer les tables de l’application.
MONTH_DAY_FORMATLien vers cette rubrique#Valeur par défaut : 'F j'
Le format par défaut à utiliser pour les champs date dans les listes pour modifications des pages de l’administration de Django, et potentiellement dans d’autres parties du système, dans les cas où seuls le mois et le jour sont affichés.
\nPar exemple, lorsqu’une page de liste pour modification de l’administration de Django est filtrée par un choix de date, l’en-tête d’un jour donné affiche le jour et le mois. Différentes locales présentent différents formats. Par exemple, l’anglais américain affichera « January 1, » alors que l’espagnol affichera « 1 Enero. ».
\nNotez que le format induit par la locale a une priorité plus élevée et remplace ce séparateur.
\nVoir chaînes de format de date autorisées. Voir aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT et YEAR_MONTH_FORMAT.
NUMBER_GROUPINGLien vers cette rubrique#Valeur par défaut : 0
Nombre de chiffres groupés dans la partie entière d’un nombre.
\nL’utilisation habituelle est d’afficher un séparateur de milliers. Si ce réglage est à 0, aucun groupement n’est effectué. S’il est plus grand que 0, THOUSAND_SEPARATOR est utilisé comme séparateur entre ces groupes.
Certaines locales utilisent un groupement des chiffres non uniforme, par ex. 10,00,00,000 pour en_IN. Dans ce cas, il est possible d’indiquer une liste avec les tailles de groupes de chiffres à appliquer. Le premier nombre définit la taille du groupe précédant le délimiteur décimal, et chaque nombre suivant définit la taille des groupes précédents. Si la liste se termine par -1, le groupement des chiffres s’arrête. Si la liste se termine par un 0, la dernière taille de groupe est utilisée pour le reste du nombre.
Tuple d’exemple pour en_IN:
NUMBER_GROUPING = (3, 2, 0)\nNotez que le format induit par la locale a une priorité plus élevée et sera donc utilisé à la place.
\nVoir aussi DECIMAL_SEPARATOR, THOUSAND_SEPARATOR et USE_THOUSAND_SEPARATOR.
PREPEND_WWWLien vers cette rubrique#Valeur par défaut : False
Indique s’il faut préfixer le sous-domaine « www. » aux URL qui ne l’ont pas. Utilisé seulement si CommonMiddleware est installé (voir Intergiciels (« Middleware »)). Voir aussi APPEND_SLASH.
ROOT_URLCONFLien vers cette rubrique#Valeur par défaut : non définie
\nUne chaîne représentant le chemin d’importation Python complet vers votre URLconf racine, par exemple "mesapplisdjango.urls". Il peut être surchargé pour chaque requête en définissant l’attribut urlconf de l’objet HttpRequest entrant. Voir Processus de traitement des requêtes par Django pour plus de détails.
SECRET_KEYLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
La clé secrète d’une installation Django. Elle est utilisée dans le contexte de la signature cryptographique, et doit être définie à une valeur unique et non prédictible.
\ndjango-admin startproject ajoute automatiquement une valeur SECRET_KEY générée aléatoirement dans chaque nouveau projet.
L’emploi de cette clé ne devrait pas présupposer qu’il s’agit de texte ou d’octets. Chaque utilisation devrait faire appel à force_str() ou force_bytes() pour la convertir dans le type souhaité.
Django refuse de démarrer si SECRET_KEY n’est pas défini.
La clé secrète est utilisée pour :
\nToutes les sessions si vous utilisez un autre moteur de sessions que django.contrib.sessions.backends.cache ou que vous utilisez la méthode get_session_auth_hash() par défaut.
Tous les messages si vous utilisez les moteurs de stockage CookieStorage ou FallbackStorage.
Tous les jetons de PasswordResetView.
Tout emploi de la signature cryptographique, sauf si une clé différente est fournie.
Losrqu’une clé secrète ne correspond plus à SECRET_KEY ou ne figure plus dans SECRET_KEY_FALLBACKS, tout les points ci-dessus seront invalidés. Lors d’une rotation de clé secrète, l’ancienne clé devrait être placée temporairement dans SECRET_KEY_FALLBACKS. Les clés secrètes ne sont pas utilisées pour les mots de passe des utilisateurs, la rotation des clés ne les touche donc pas.
SECRET_KEY_FALLBACKSLien vers cette rubrique#Valeur par défaut : []
Une liste de clés secrètes de repli pour une installation particulière de Django. Elles permettent d’effectuer des rotations de la clé SECRET_KEY.
Afin d’effectuer une rotation des clés secrètes, définissez une nouvelle SECRET_KEY et placez l’ancienne valeur au début de la liste SECRET_KEY_FALLBACKS. Puis enlevez les anciennes valeurs en fin de SECRET_KEY_FALLBACKS lorsque vous pensez être prêt à faire expirer les sessions, jetons de réinitialisation de mots de passe, etc. encore liés à ces anciennes clés.
L’emploi des valeurs de clé secrète ne devrait pas présupposer qu’il s’agit de texte ou d’octets. Chaque utilisation devrait faire appel à force_str() ou force_bytes() pour la convertir dans le type souhaité.
SECURE_CONTENT_TYPE_NOSNIFFLien vers cette rubrique#Valeur par défaut : True
Si True, l’intergiciel SecurityMiddleware définit l’en-tête X-Content-Type-Options: nosniff pour toutes les réponses qui ne l’ont pas déjà.
SECURE_CROSS_ORIGIN_OPENER_POLICYLien vers cette rubrique#Valeur par défaut : 'same-origin'
S’il ne contient pas None, l’intergiciel SecurityMiddleware définit l’en-tête Politique d’ouverture d’origine croisée pour toutes les réponses qui ne l’ont pas déjà avec la valeur indiquée.
SECURE_CSPLien vers cette rubrique#Valeur par défaut : {}
Ce réglage définit les directives utilisées par ContentSecurityPolicyMiddleware, qui génère et ajoute un en-tête Content-Security-Policy (CSP) à toutes les réponses qui n’en contiennent pas déjà un.
L’en-tête Content-Security-Policy indique aux navigateurs de restreindre les ressources qu’une page a le droit de charger. Un CSP correctement configuré peut bloquer du contenu qui viole les règles définies, ce qui aide à combattre les attaques par script intersites et d’autres visant à l’injection de contenu, en déclarant explicitement les sources fiables pour les contenus tels que les scripts, les styles, les images, les polices et d’autres encore.
Ce réglage doit être une correspondance (typiquement un dictionnaire) de noms de directives et de leurs valeurs. Chaque clé doit être une directive CSP valable, telle que default-src ou script-src. La valeur correspondante peut être une liste, un tuple, ou un ensemble d’expressions sources ou d’URL admises pour cette directive. Si un ensemble est utilisé, il sera automatiquement trié pour garantir un résultat cohérent dans les en-têtes générés.
Cet exemple illustre la structure attendue, utilisant les constantes définies dans Constantes CSP:
\nfrom django.utils.csp import CSP\n\nSECURE_CSP = {\n "default-src": [CSP.SELF],\n "img-src": ["data:", CSP.SELF, "https://images.example.com"],\n "frame-src": [CSP.NONE],\n}\nSECURE_CSP_REPORT_ONLYLien vers cette rubrique#Valeur par défaut : {}
This setting is just like SECURE_CSP, but instead of enforcing the\npolicy, it instructs the\nContentSecurityPolicyMiddleware to apply a\nContent-Security-Policy-Report-Only header to responses, which allows\nbrowsers to monitor and report policy violations without blocking content. This\nis useful for testing and refining a policy before enforcement.
Most browsers log CSP violations to the developer console and can optionally\nsend them to a reporting endpoint. To collect these reports, the report-uri\ndirective must be defined (see Rapports de violation de politique for more details).
As noted in the MDN documentation on Content-Security-Policy-Report-Only,\nthe report-uri directive must be specified for reports to be sent;\notherwise, the header has no reporting effect (other than logging to the\nbrowser’s developer tools console).
Following the example from the SECURE_CSP setting:
from django.utils.csp import CSP\n\nSECURE_CSP_REPORT_ONLY = {\n "default-src": [CSP.SELF],\n "img-src": ["data:", CSP.SELF, "https://images.example.com"],\n "frame-src": [CSP.NONE],\n "report-uri": "/my-site/csp/reports/",\n}\nSECURE_HSTS_INCLUDE_SUBDOMAINSLien vers cette rubrique#Valeur par défaut : False
Si True, l’intergiciel SecurityMiddleware ajoute la directive includeSubDomains à l’en-tête Sécurité de transport HTTP stricte (HSTS). Il n’a pas d’effet tant que SECURE_HSTS_SECONDS ne contient pas une valeur différente de zéro.
SECURE_HSTS_PRELOADLien vers cette rubrique#Valeur par défaut : False
Si True, l’intergiciel SecurityMiddleware ajoute la directive preload à l’en-tête Sécurité de transport HTTP stricte (HSTS). Il n’a pas d’effet tant que SECURE_HSTS_SECONDS ne contient pas une valeur différente de zéro.
SECURE_HSTS_SECONDSLien vers cette rubrique#Valeur par défaut : 0
Si défini à un nombre entier autre que 0, l’intergiciel SecurityMiddleware définit l’en-tête Sécurité de transport HTTP stricte (HSTS) pour toutes les réponses qui ne l’ont pas déjà.
SECURE_PROXY_SSL_HEADERLien vers cette rubrique#Valeur par défaut : None
Un tuple représentant une combinaison en-tête/valeur HTTP signifiant qu’une requête est sécurisée. Ce réglage contrôle le comportement de la méthode is_secure() de l’objet requête.
Par défaut, is_secure() détermine si une requête est sécurisée en vérifiant que le protocole de l’URL demandée utilise https://. Cette méthode est importante pour la protection CSRF de Django et peut être utilisée par votre propre code ou des applications tierces.
Si votre application Django est derrière un serveur mandataire (proxy), celui-ci peut masquer le fait que la requête est en HTTPS. Si une connexion non HTTPS est établie entre le serveur mandataire et Django, is_secure() renvoie toujours False, même pour les requêtes qui ont été initiées en HTTPS par l’utilisateur final. Au contraire, si une connexion HTTPS est établie entre le serveur mandataire et Django, is_secure() renvoie toujours True, même pour les requêtes qui ont été originellement initiées en HTTP.
Dans cette situation, configurez votre serveur mandataire pour qu’il définisse un en-tête HTTP indiquant à Django si la requête est arrivée en HTTPS ; le réglage SECURE_PROXY_SSL_HEADER permet de signaler à Django le nom de l’en-tête où il doit chercher cette information.
Définissez un tuple contenant deux éléments : le nom de l’en-tête à examiner et la valeur requise. Par exemple :
\nSECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")\nCela indique à Django de faire confiance à l’en-tête X-Forwarded-Proto ajouté par le serveur mandataire et que la requête provient bien d’une connexion sécurisée (c’est-à-dire qu’elle est arrivée par HTTPS), quand :
la valeur de l’en-tête est 'https' ou
sa valeur initiale la plus à gauche est 'https' dans le cas d’une liste de protocoles séparés par une virgule (ex: 'https,http,http').
Ce réglage ne doit être défini qu’à la condition que vous soyez maître du serveur mandataire ou que vous ayez la garantie que l’en-tête soit ajouté ou enlevé de manière appropriée.
\nNotez que le nom de l’en-tête doit être dans le format utilisé par request.META, tout en majuscules et commençant probablement par HTTP_ (souvenez-vous que Django ajoute automatiquement 'HTTP_' au début des noms d’en-têtes X avant de les rendre accessibles dans request.META).
SECURE_REDIRECT_EXEMPTLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Si un chemin d’URL correspond à une expression régulière de cette liste, la requête ne sera pas redirigée vers HTTPS. Comme l’intergiciel SecurityMiddleware enlève les barres obliques initiales des chemins d’URL, les motifs ne doivent pas les inclure, par ex. SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]. Si SECURE_SSL_REDIRECT vaut False, ce réglage n’a pas d’effet.
SECURE_REFERRER_POLICYLien vers cette rubrique#Valeur par défaut : 'same-origin'
S’il est configuré, l’intergiciel SecurityMiddleware définit l’en-tête Politique de référencement pour toutes les réponses qui ne l’ont pas déjà avec la valeur indiquée.
SECURE_SSL_HOSTLien vers cette rubrique#Valeur par défaut : None
Si défini à une chaîne (par ex. secure.example.com), toutes les redirections SSL seront redirigées vers cet hôte au lieu de l’hôte d’origine (par ex. www.example.com). Si SECURE_SSL_REDIRECT vaut False, ce réglage n’as pas d’effet.
SECURE_SSL_REDIRECTLien vers cette rubrique#Valeur par défaut : False
Si True, SecurityMiddleware redirige toutes les requêtes non HTTPS vers HTTPS (sauf pour les URL correspondant à une expression régulière figurant dans SECURE_REDIRECT_EXEMPT).
SERIALIZATION_MODULESLien vers cette rubrique#Valeur par défaut : non définie
\nUn dictionnaire de modules contenant des définitions de sérialiseurs (sous forme de chaînes) dont les clés sont des identifiants textuels pour le type de sérialisation correspondant. Par exemple, pour définir un sérialiseur YAML :
\nSERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}\nSERVER_EMAILLien vers cette rubrique#Valeur par défaut : 'root@localhost'
L’adresse de courriel de provenance des messages d’erreur, tels que ceux envoyés aux ADMINS et aux MANAGERS. Cette adresse est utilisée dans l’en-tête From: et accepte tout format valide pour le protocole d’envoi de courriel configuré.
To build an address with a display name from variable content, see\nFormatting email addresses.
\n\nSHORT_DATE_FORMATLien vers cette rubrique#Valeur par défaut : 'm/d/Y' (ex . : 12/31/2003)
Un format disponible pour l’affichage des champs dates dans les gabarits. Notez que le format induit par la locale a une priorité plus élevée et remplacera ce format. Voir les chaînes de format de date autorisées.
Voir aussi DATE_FORMAT et SHORT_DATETIME_FORMAT.
SHORT_DATETIME_FORMATLien vers cette rubrique#Valeur par défaut : 'm/d/Y P' (ex . : 12/31/2003 4 p.m.)
Un format disponible pour l’affichage des champs dates/heures dans les gabarits. Notez que le format induit par la locale a une priorité plus élevée et remplacera ce format. Voir les chaînes de format de date autorisées.
Voir aussi DATE_FORMAT et SHORT_DATE_FORMAT.
SIGNING_BACKENDLien vers cette rubrique#Valeur par défaut : 'django.core.signing.TimestampSigner'
Le moteur utilisé pour signer les cookies et d’autres données.
\nVoir aussi la documentation sur Signatures cryptographiques.
\nSILENCED_SYSTEM_CHECKSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste d’identifiants de messages générés par l’infrastructure de contrôle système (par ex: ["models.W001"]) que vous souhaitez ignorer de manière permanente. Les contrôles ainsi masqués n’apparaissent plus dans la console.
Voir aussi la documentation Infrastructure de contrôle système.
\nSTORAGESLien vers cette rubrique#Valeur par défaut :
\n{\n "default": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n },\n "staticfiles": {\n "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",\n },\n}\nUn dictionnaire contenant les réglages de tous les stockages à utiliser avec Django. C’est un dictionnaire imbriqué dont les contenus font correspondre l’alias de stockage avec un dictionnaire contenant les options de chacun des stockages.
\nLe choix d’alias de stockage est libre. Cependant, deux noms d’alias ont une signification particulière :
\ndefault pour la gestion des fichiers. 'django.core.files.storage.FileSystemStorage' est le moteur de stockage par défaut.
staticfiles pour la gestion des fichiers statiques. 'django.contrib.staticfiles.storage.StaticFilesStorage' est le moteur de stockage par défaut.
Voici un exemple d’extrait de settings.py définissant un stockage de fichiers personnalisé appelé example:
STORAGES = {\n # ...\n "example": {\n "BACKEND": "django.core.files.storage.FileSystemStorage",\n "OPTIONS": {\n "location": "/example",\n "base_url": "/example/",\n },\n },\n}\nLes OPTIONS sont transmises au moteur BACKEND comme paramètres **kwargs lors de son initialisation.
Une instance prête à l’emploi des moteurs de stockage peut être obtenue à partir de django.core.files.storage.storages. Utilisez une clé correspondant à la définition du moteur dans STORAGES.
TASKSLien vers cette rubrique#Valeur par défaut :
\n{\n "default": {\n "BACKEND": "django.tasks.backends.immediate.ImmediateBackend",\n }\n}\nA dictionary containing the settings for all Task backends to be used with\nDjango. It is a nested dictionary whose contents maps backend aliases to a\ndictionary containing the options for each backend.
\nThe TASKS setting must configure a default backend; any number\nof additional backends may also be specified. Depending on which backend is\nused, other options may be required. The following options are available as\nstandard.
BACKENDLien vers cette rubrique#Valeur par défaut : '' (Chaîne vide)
The Tasks backend to use. The built-in backends are:
\n'django.tasks.backends.dummy.DummyBackend'
'django.tasks.backends.immediate.ImmediateBackend'
You can use a backend that doesn’t ship with Django by setting\nBACKEND to a fully-qualified path of a backend\nclass (i.e. mypackage.backends.whatever.WhateverBackend).
QUEUESLien vers cette rubrique#Default: ["default"]
Specify the queue names supported by the backend. This can be used to ensure\nTasks aren’t enqueued to queues which do not exist.
\nTo disable queue name validation, set to an empty list ([]).
OPTIONSLien vers cette rubrique#Valeur par défaut : {}
Extra parameters to pass to the Task backend. Available parameters vary\ndepending on the Task backend.
\nTEMPLATESLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Une liste contenant les réglages de tous les moteurs de gabarit à utiliser avec Django. Chaque élément de la liste est un dictionnaire contenant les options de chacun des moteurs.
\nVoici une configuration qui indique au moteur de gabarit de Django de charger les gabarits à partir du sous-répertoire templates de chaque application installée :
TEMPLATES = [\n {\n "BACKEND": "django.template.backends.django.DjangoTemplates",\n "APP_DIRS": True,\n },\n]\nLes options suivantes sont disponibles pour tous les moteurs.
\nBACKENDLien vers cette rubrique#Valeur par défaut : non définie
\nLe moteur de gabarit à utiliser. Les moteurs de gabarit intégrés à Django sont :
\n'django.template.backends.django.DjangoTemplates'
'django.template.backends.jinja2.Jinja2'
Vous pouvez utiliser un moteur de gabarit non livré avec Django en définissant BACKEND à un chemin complètement qualifié (par ex. monpaquet.moteurs.Backend).
NAMELien vers cette rubrique#Valeur par défaut :: voir ci-dessous
\nL’alias de ce moteur de gabarit particulier. Il s’agit d’un identifiant qui permet de choisir un moteur pour le processus de rendu. Les alias doivent être uniques parmi tous les moteurs de gabarit configurés.
\nSa valeur par défaut contient le nom du module définissant la classe du moteur, c’est-à-dire l’avant-dernier élément de BACKEND, lorsque celui-ci est présent. Par exemple, si le moteur est 'mypackage.whatever.Backend', le nom par défaut vaut 'whatever'.
DIRSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Répertoires dans lesquels le moteur recherche des fichiers sources de gabarits, dans l’ordre de leur recherche.
\nAPP_DIRSLien vers cette rubrique#Valeur par défaut : False
Indique si le moteur recherche des fichiers sources de gabarits dans les applications installées.
\n\nOPTIONSLien vers cette rubrique#Valeur par défaut : {} (dictionnaire vide)
Paramètres supplémentaires à passer au moteur de gabarit. Les paramètres disponibles varient en fonction du moteur. Voir DjangoTemplates et Jinja2 pour les options des moteurs intégrés.
TEST_RUNNERLien vers cette rubrique#Par défaut : django.test.runner.DiscoverRunner
Le nom de la classe à utiliser pour lancer la suite de tests. Voir Utilisation d’autres infrastructures de test.
\nTEST_NON_SERIALIZED_APPSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Afin de pouvoir restaurer l’état de la base de données entre les tests pour les classes TransactionTestCase et les moteurs de base de données non transactionnels, Django sérialise le contenu de toutes les applications lorsqu’il lance la suite de tests pour pouvoir ensuite recharger ces données copiées avant de lancer les tests qui ont en besoin.
Cela ralentit le démarrage du lanceur de tests ; si vous savez que certaines applications n’ont pas besoin de cette fonctionnalité, vous pouvez ajouter leur nom complet dans ce réglage (par ex. 'django.contrib.contenttypes') pour les exclure du processus de sérialisation.
THOUSAND_SEPARATORLien vers cette rubrique#Valeur par défaut : ',' (virgule)
Séparateur de milliers utilisé par défaut lors de la mise en forme de nombres. Ce réglage n’est utilisé que lorsque USE_THOUSAND_SEPARATOR vaut True et que NUMBER_GROUPING est plus grand que 0.
Notez que le format induit par la locale a une priorité plus élevée et sera donc utilisé à la place.
\nVoir aussi NUMBER_GROUPING, DECIMAL_SEPARATOR et USE_THOUSAND_SEPARATOR.
TIME_FORMATLien vers cette rubrique#Valeur par défaut : 'P'` (ex . : ``4 p.m.)
Le format par défaut pour l’affichage des champs heures dans les différentes parties du système. Notez que le format induit par la locale a une priorité plus élevée et remplacera ce format. Voir les chaînes de format de date autorisées.
Voir aussi DATE_FORMAT et DATETIME_FORMAT.
TIME_INPUT_FORMATSLien vers cette rubrique#Valeur par défaut :
\n[\n "%H:%M:%S", # '14:30:59'\n "%H:%M:%S.%f", # '14:30:59.000200'\n "%H:%M", # '14:30'\n]\nUne liste de formats qui seront acceptés lors de la saisie de données dans un champ heure. Les formats seront testés dans l’ordre et le premier correspondant sera utilisé. Notez que ces chaînes de format utilisent la syntaxe du module datetime de Python, et non pas celle des chaînes de format du filtre de gabarit date.
Le format induit par la locale a une priorité plus élevée et remplace ce séparateur.
\nVoir aussi DATE_INPUT_FORMATS et DATETIME_INPUT_FORMATS.
TIME_ZONELien vers cette rubrique#Valeur par défaut : 'America/Chicago'
Une chaîne représentant le fuseau horaire pour cette installation. Voir la liste des fuseaux horaires.
\n\nNotez que cela ne correspond pas forcément au fuseau horaire du serveur. Par exemple, il est imaginable qu’un site serve plusieurs instances de sites Django, chacun ayant leur propre réglage de fuseau horaire.
\nLorsque USE_TZ est défini à False, ce réglage définit le fuseau horaire avec lequel Django stocke tous les objets dates/heures. Lorsque USE_TZ est défini à True, il s’agit alors du fuseau horaire que Django utilise par défaut pour afficher les dates/heures dans les gabarits et pour interpréter les valeurs dates/heures saisies dans les formulaires.
Dans les environnements Unix (où time.tzset() est implémenté), Django définit la variable os.environ['TZ'] au fuseau horaire défini dans le réglage TIME_ZONE. Ainsi, toutes les vues et tous les modèles opèrent automatiquement dans ce fuseau horaire. Cependant, Django ne définit pas la variable d’environnement TZ si vous utilisez l’option de configuration manuelle décrite dans configuration manuelle des réglages. Si Django ne définit pas la variable d’environnement TZ, c’est à vous de vous assurer que les processus fonctionnent dans le bon environnement.
USE_BLANK_CHOICE_DASHLien vers cette rubrique#Valeur par défaut : False
The default blank choice label in Select widgets was changed from\n"---------" to django.db.models.fields.BLANK_CHOICE_LABEL. Set this\ntransitional setting to True to revert to the previous label.
USE_I18NLien vers cette rubrique#Valeur par défaut : True
Une valeur booléenne indiquant si le système de traduction de Django doit être activé. C’est un moyen de le désactiver pour gagner un peu de performances. Si défini à False, Django optimise son fonctionnement pour ne pas charger le mécanisme de traduction.
Voir aussi LANGUAGE_CODE et USE_TZ.
USE_THOUSAND_SEPARATORLien vers cette rubrique#Valeur par défaut : False
Une valeur booléenne indiquant si les nombres doivent être affichés avec des séparateurs de milliers. Lorsque ce réglage vaut True, Django met en forme les nombres en utilisant les valeurs des réglages NUMBER_GROUPING et THOUSAND_SEPARATOR. Ces deux derniers réglages peuvent aussi être définis par la locale active qui est prioritaire.
Voir aussi DECIMAL_SEPARATOR, NUMBER_GROUPING et THOUSAND_SEPARATOR.
USE_TZLien vers cette rubrique#Valeur par défaut : True
Une valeur booléenne indiquant si les dates/heures sont conscientes de leur fuseau horaire. Si défini à True, Django utilise en interne des dates/heures conscientes de leur fuseau horaire.
Lorsque USE_TZ vaut False, Django utilise des dates/heures naïves en temps local, sauf si des dates mises en forme en ISO 8601 et contenant un fuseau horaire sont interprétées ; dans ce cas, le fuseau horaire est conservé.
USE_X_FORWARDED_HOSTLien vers cette rubrique#Valeur par défaut : False
Une valeur booléenne indiquant si l’en-tête X-Forwarded-Host doit être favorisé aux dépends de l’en-tête Host. Ceci ne devrait être activé que dans le cas où un serveur mandataire définit cet en-tête en amont de votre application.
Ce réglage a la priorité sur USE_X_FORWARDED_PORT. Selon la RFC 7239 Section 5.3, l’en-tête X-Forwarded-Host peut inclure le numéro de port, auquel cas il ne faudrait pas utiliser USE_X_FORWARDED_PORT.
USE_X_FORWARDED_PORTLien vers cette rubrique#Valeur par défaut : False
Une valeur booléenne indiquant si l’en-tête X-Forwarded-Port doit être favorisé aux dépends de la variable META SERVER_PORT. Ceci ne devrait être activé que dans le cas où un serveur mandataire définit cet en-tête en amont de votre application.
USE_X_FORWARDED_HOST a la priorité sur ce réglage.
URLIZE_ASSUME_HTTPSLien vers cette rubrique#Valeur par défaut : False
Set this transitional setting to True to opt into using HTTPS as the\ndefault protocol when none is provided in URLs processed by the\nurlize and urlizetrunc template filters during the Django\n6.x release cycle.
WSGI_APPLICATIONLien vers cette rubrique#Valeur par défaut : None
Le chemin Python complet de l’objet application WSGI que les serveurs intégrés dans Django vont utiliser (par ex. runserver). La commande de gestion django-admin startproject crée un fichier wsgi.py standard contenant un exécutable application et fait pointer ce réglage vers cet objet application.
Si indéfini, c’est la valeur renvoyée par django.core.wsgi.get_wsgi_application() qui sera utilisée. Dans ce cas, le comportement de runserver sera le même que lors des versions précédentes de Django.
YEAR_MONTH_FORMATLien vers cette rubrique#Valeur par défaut : 'F Y'
Le format par défaut à utiliser pour les champs date dans les listes pour modifications des pages de l’administration de Django, et potentiellement dans d’autres parties du système, dans les cas où seuls l’année et le mois sont affichés.
\nPar exemple, lorsqu’une page de liste pour modification de l’administration de Django est filtrée par un choix de date, l’en-tête d’un mois donné affiche le mois et l’année. Différentes locales présentent différents formats. Par exemple, l’anglais américain affichera « January 2006, » alors qu’une autre locale affichera peut-être « 2006/January. ».
\nNotez que le format induit par la locale a une priorité plus élevée et remplace ce séparateur.
\nVoir chaînes de format de date autorisées. Voir aussi DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT et MONTH_DAY_FORMAT.
X_FRAME_OPTIONSLien vers cette rubrique#Valeur par défaut : 'DENY'
La valeur par défaut de l’en-tête X-Frame-Options utilisé par XFrameOptionsMiddleware. Voir la documentation sur la protection contre le détournement de clic.
Réglages pour django.contrib.auth.
AUTHENTICATION_BACKENDSLien vers cette rubrique#Valeur par défaut : ['django.contrib.auth.backends.ModelBackend']
Une liste de classes de moteurs d’authentification (sous forme de chaînes) à utiliser durant la tentative d’authentification d’un utilisateur. Consultez la documentation sur les moteurs d’authentification pour plus de détails.
\nAUTH_USER_MODELLien vers cette rubrique#Valeur par défaut : 'auth.User'
Le modèle à utiliser pour représenter un utilisateur. Voir Substitution par un modèle User personnalisé.
\n\nLOGIN_REDIRECT_URLLien vers cette rubrique#Valeur par défaut : '/accounts/profile/'
L’URL ou le motif d’URL nommé vers lequel seront redirigées les requêtes après la connexion si la vue LoginView ne reçoit pas de paramètre GET next.
LOGIN_URLLien vers cette rubrique#Valeur par défaut : '/accounts/login/'
L’URL ou le motif d’URL nommé vers lequel seront redirigées les requêtes pour la connexion avec le décorateur login_required(), les classes LoginRequiredMixin, AccessMixin ou quand l’intergiciel LoginRequiredMiddleware est installé.
LOGOUT_REDIRECT_URLLien vers cette rubrique#Valeur par défaut : None
L’URL ou le motif d’URL nommé vers lequel seront redirigées les requêtes après la déconnexion si la vue LogoutView ne possède pas d’attribut next_page.
Avec None, aucune redirection n’est effectuée et la vue de déconnexion logout sera produite.
PASSWORD_RESET_TIMEOUTLien vers cette rubrique#Valeur par défaut : 259200 (3 jours, en secondes)
La durée de validité d’un lien de réinitialisation de mot de passe, en secondes.
\nUtilisé par PasswordResetConfirmView.
PASSWORD_HASHERSLien vers cette rubrique#Voir Stockage des mots de passe par Django.
\nValeur par défaut :
\n[\n "django.contrib.auth.hashers.PBKDF2PasswordHasher",\n "django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",\n "django.contrib.auth.hashers.Argon2PasswordHasher",\n "django.contrib.auth.hashers.BCryptSHA256PasswordHasher",\n "django.contrib.auth.hashers.ScryptPasswordHasher",\n]\nAUTH_PASSWORD_VALIDATORSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
La liste des validateurs utilisés pour vérifier la solidité des mots de passe des utilisateurs. Voir Validation des mots de passe pour plus de détails. Par défaut, aucune validation n’est effectuée et tous les mots de passe sont acceptés.
\nRéglages pour django.contrib.messages.
MESSAGE_LEVELLien vers cette rubrique#Valeur par défaut : messages.INFO
Définit le niveau minimum des messages qui seront traités par le système des messages. Voir les niveaux de message pour plus de détails.
\n\nMESSAGE_STORAGELien vers cette rubrique#Valeur par défaut : 'django.contrib.messages.storage.fallback.FallbackStorage'
Contrôle l’emplacement de stockage des données de messages. Les valeurs possibles sont :
\n'django.contrib.messages.storage.fallback.FallbackStorage'
'django.contrib.messages.storage.session.SessionStorage'
'django.contrib.messages.storage.cookie.CookieStorage'
Voir les moteurs de stockage de messages pour plus de détails.
\nLes moteurs qui utilisent des cookies – CookieStorage et FallbackStorage – utilisent les valeurs de SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE et SESSION_COOKIE_HTTPONLY lors de la définition de leurs cookies.
Réglages pour django.contrib.sessions.
SESSION_CACHE_ALIASLien vers cette rubrique#Valeur par défaut : 'default'
Si vous utilisez le stockage des sessions basé en cache, ce réglage choisit le cache à utiliser.
\nSESSION_ENGINELien vers cette rubrique#Valeur par défaut : 'django.contrib.sessions.backends.db'
Contrôle l’emplacement de stockage des données de sessions. Les moteurs inclus sont :
\n'django.contrib.sessions.backends.db'
'django.contrib.sessions.backends.file'
'django.contrib.sessions.backends.cache'
'django.contrib.sessions.backends.cached_db'
'django.contrib.sessions.backends.signed_cookies'
Voir Configuration du moteur de sessions pour plus de détails.
\nSESSION_EXPIRE_AT_BROWSER_CLOSELien vers cette rubrique#Valeur par défaut : False
Indique s’il faut que la session expire lorsque l’utilisateur ferme son navigateur. Voir Expiration ou persistance des sessions.
\nSESSION_FILE_PATHLien vers cette rubrique#Valeur par défaut : None
Si vous utilisez le stockage de sessions basé sur des fichiers, cela définit le répertoire dans lequel Django stocke les données de sessions. Avec la valeur par défaut (None), Django utilise le répertoire temporaire standard du système.
SESSION_SAVE_EVERY_REQUESTLien vers cette rubrique#Valeur par défaut : False
Indique si les données de sessions sont enregistrées lors de chaque requête. Avec la valeur False (par défaut), Django n’enregistre la session dans la base de données qu’au moment où la session a été modifiée, c’est-à-dire qu’au moins une des valeurs de son dictionnaire a été définie ou supprimée. Les sessions vides ne seront pas créées, même si ce réglage est activé.
SESSION_SERIALIZERLien vers cette rubrique#Par défaut : 'django.contrib.sessions.serializers.JSONSerializer'
Chemin d’importation complet d’une classe de sérialisation à utiliser pour la sérialisation des données de session. Le sérialiseur inclus est :
\n'django.contrib.sessions.serializers.JSONSerializer'
Voir Sérialisation des sessions pour plus de détails.
\nRéglages pour django.contrib.sites.
SITE_IDLien vers cette rubrique#Valeur par défaut : non définie
\nL’identifiant (nombre entier) du site actuel dans la table de base de données django_site. Peut être utilisé par les applications pour lier leurs données à des sites spécifiques et ainsi gérer dans une même base de données du contenu pour plusieurs sites.
Réglages pour django.contrib.staticfiles.
STATIC_ROOTLien vers cette rubrique#Valeur par défaut : None
Le chemin absolu vers le répertoire dans lequel collectstatic rassemble les fichiers statiques en vue du déploiement.
Exemple : "/var/www/example.com/static/"
Si l’application complémentaire staticfiles est activée (c’est le cas dans le modèle de projet par défaut), la commande d’administration collectstatic rassemble les fichiers statiques dans ce répertoire. Consultez le guide pratique sur la gestion des fichiers statiques pour plus de détails sur son utilisation.
STATIC_URLLien vers cette rubrique#Valeur par défaut : None
URL utilisée pour se référer aux fichiers statiques se trouvant dans STATIC_ROOT.
Exemple : "static/" ou "https://static.example.com/"
Si ce réglage ne vaut pas None, il est utilisé comme chemin de base pour les définitions de fichiers annexes (la classe Media) et l’application staticfiles.
Cette valeur doit se terminer par une barre oblique quand elle est définie.
\nVous devrez peut-être configurer ces fichiers pour être servis en développement et aurez sans aucun doute besoin de le faire en production.
\n\nSTATICFILES_DIRSLien vers cette rubrique#Valeur par défaut : [] (liste vide)
Ce réglage définit les emplacements supplémentaires que l’application staticfiles parcourt si la recherche par FileSystemFinder est activée, par exemple quand vous utilisez la commande de gestion collectstatic ou findstatic, ou quand vous utilisez la vue de service de fichiers statiques.
Il devrait contenir une liste de chaînes contenant les chemins complets vers les répertoires de fichiers supplémentaires ; par exemple :
\nSTATICFILES_DIRS = [\n "/home/special.polls.com/polls/static",\n "/home/polls.com/polls/static",\n "/opt/webfiles/common",\n]\nNotez que ces chemins doivent utiliser des barres obliques de type Unix, même sur Windows (par ex. "C:/Users/user/mon_site/contenu_statique_suppl").
Dans le cas où vous souhaiteriez vous référer aux fichiers d’un des emplacements avec un espace de noms supplémentaire, il est possible d’indiquer un préfixe sous la forme de tuples (préfixe, chemin), comme par exemple :
STATICFILES_DIRS = [\n # ...\n ("downloads", "/opt/webfiles/stats"),\n]\nPar exemple, en supposant que STATIC_URL soit défini à static/, la commande de gestion collectstatic recueillera les fichiers « stats » dans un sous-répertoire 'downloads' de STATIC_ROOT.
Cela permettrait de se référer au fichier local '/opt/webfiles/stats/polls_20101022.tar.gz' par '/static/downloads/polls_20101022.tar.gz' dans les gabarits ; par exemple :
<a href="{% static 'downloads/polls_20101022.tar.gz' %}">\nSTATICFILES_FINDERSLien vers cette rubrique#Valeur par défaut :
\n[\n "django.contrib.staticfiles.finders.FileSystemFinder",\n "django.contrib.staticfiles.finders.AppDirectoriesFinder",\n]\nLa liste des moteurs de découverte sachant retrouver les fichiers statiques en divers endroits.
\nLe comportement par défaut recherche les fichiers stockés aux emplacements du réglage STATICFILES_DIRS (en utilisant django.contrib.staticfiles.finders.FileSystemFinder) et dans un sous-répertoire static de chaque application (en utilisant django.contrib.staticfiles.finders.AppDirectoriesFinder). Si plusieurs fichiers de même nom sont présents, le premier fichier trouvé est utilisé.
Un moteur de découverte est désactivé par défaut : django.contrib.staticfiles.finders.DefaultStorageFinder. S’il est ajouté au réglage STATICFILES_FINDERS, il recherche les fichiers statiques dans l’emplacement de stockage des fichiers par défaut tel que défini par la clé default du réglage STORAGES.
Les moteurs de découverte de fichiers statiques sont actuellement considérés comme une interface privée, ce qui explique que cette interface n’est pas documentée.
\ni18n/l10n)Lien vers cette rubrique#i18n)Lien vers cette rubrique#l10n)Lien vers cette rubrique#Sécurité
\n\nProtection contre le « Cross site request forgery » (CSRF)
\n\nBase de données : TEST