Advertencia
Ten cuidado al sobreescribir configuraciones, especialmente cuando el valor por defecto es una lista o diccionario no vacío, como STATICFILES_FINDERS. Asegúrese de mantener los componentes requeridos por las características de Django que desee utilizar.
Aquí tienes la lista de configuraciones disponibles en el núcleo de Django y sus valores por defecto. Las configuraciones proporcionadas por apps contribuyentes se listan a continuación, seguidas de un índice temático de las configuraciones del núcleo. Para material introductorio, vea la guía de temas sobre configuraciones.
ABSOLUTE_URL_OVERRIDES¶Default: {} (Diccionario vacío)
Un diccionario que mapea cadenas de la forma "app_label.model_name" a funciones que toman un objeto modelo y devuelven su URL. Esta es una manera de insertar o sobreescribir los métodos get_absolute_url() en una base por instalación. Ejemplo:
ABSOLUTE_URL_OVERRIDES = {
"blogs.blog": lambda o: "/blogs/%s/" % o.slug,
"news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}
El nombre del modelo utilizado en esta configuración debe estar en minúsculas, independientemente del caso del nombre real de la clase del modelo.
ADMINS¶Default: [] (Lista vacía)
Una lista de todas las personas que reciben notificaciones de errores de código. Cuando DEBUG=False y AdminEmailHandler está configurado en LOGGING (lo hace por defecto), Django envía un correo electrónico a estas personas con los detalles de las excepciones levantadas en el ciclo de solicitud/respuesta.
Cada elemento de la lista debe ser una tupla de (nombre completo, dirección de correo electrónico). Ejemplo:
[("John", "john@example.com"), ("Mary", "mary@example.com")]
ALLOWED_HOSTS¶Default: [] (Lista vacía)
Una lista de cadenas que representan los nombres de host/dominio a los que puede servir este sitio Django. Esta es una medida de seguridad para prevenir ataques por encabezado Host, que son posibles incluso bajo muchas configuraciones del servidor web que parecen seguras.
Los valores en esta lista pueden ser nombres de dominio completos (por ejemplo, 'www.example.com'), en cuyo caso se compararán con el encabezado Host de la solicitud exactamente (caso insensible, sin incluir puerto). Un valor que comienza con un punto se puede utilizar como wildcard de subdominio: '.example.com' coincidirá con example.com, www.example.com y cualquier otro subdominio de example.com. Un valor de '*' coincidirá con cualquier cosa; en este caso, es responsable de proporcionar su propia validación del encabezado Host (quizás en un middleware; si es así, este middleware debe estar listado primero en MIDDLEWARE).
Django también permite el nombre de dominio completo cualificado (FQDN)_<nombre-de-referencia> de cualquier entrada. Algunos navegadores incluyen un punto final en la cabecera Host que Django elimina al realizar la validación del host.
Si la cabecera Host (o X-Forwarded-Host si está habilitada USE_X_FORWARDED_HOST) no coincide con ningún valor de esta lista, el método django.http.HttpRequest.get_host() levantará una SuspiciousOperation.
Cuando DEBUG es True y ALLOWED_HOSTS está vacío, el host se valida contra ['.localhost', '127.0.0.1', '[::1]'].
La validación de ALLOWED_HOSTS también se realiza cuando se ejecutan pruebas <topics-testing-advanced-multiple-hosts>.
Esta validación solo aplica a través del método get_host(); si tu código accede directamente a la cabecera Host desde request.META estás evitando esta protección de seguridad.
APPEND_SLASH¶Predeterminado: True
Cuando se establece en True, si la URL de solicitud no coincide con ninguno de los patrones del URLconf y no termina con una barra, se emite un redireccionamiento HTTP a la misma URL con una barra agregada. Ten en cuenta que el redireccionamiento puede provocar la pérdida de cualquier dato enviado en una solicitud POST.
La configuración APPEND_SLASH solo se utiliza si está instalado CommonMiddleware (consulte Middleware). Consulta también PREPEND_WWW.
CACHES¶Predeterminado:
{
"default": {
"BACKEND": "django.core.cache.backends.locmem.LocMemCache",
}
}
Un diccionario que contiene las configuraciones para todos los cachés a utilizar con Django. Es un diccionario anidado cuyos contenidos mapean alias de caché a un diccionario que contiene las opciones para un caché individual.
La configuración CACHES debe configurar un default caché; también se pueden especificar cualquier número adicional de cachés. Si está utilizando un backend de caché distinto del caché en memoria local, o necesita definir múltiples cachés, serán necesarias otras opciones. Las siguientes opciones de caché están disponibles.
BACKEND¶Por defecto: '' (cadena vacía)
El backend del caché a utilizar. Los backends de caché integrados son:
'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'
Puedes utilizar un backend de caché que no viene incluido con Django estableciendo BACKEND a una ruta completa y cualificada de la clase del backend de caché (i.e. mypackage.backends.whatever.WhateverCache).
KEY_FUNCTION¶Una cadena que contiene un camino puntoado a una función (o cualquier llamable) que define cómo componer una prefijo, versión y clave en una clave de caché final. La implementación predeterminada es equivalente a la función:
def make_key(key, key_prefix, version):
return ":".join([key_prefix, str(version), key])
Puedes utilizar cualquier función de clave que desees, siempre y cuando tenga el mismo firmado de argumentos.
Consulte la documentación del cache para obtener más información.
KEY_PREFIX¶Por defecto: '' (cadena vacía)
Una cadena que se incluirá automáticamente (se prependerá por defecto) a todas las claves de caché utilizadas por el servidor Django.
Consulte la documentación del cache para obtener más información.
UBICACIÓN¶Por defecto: '' (cadena vacía)
La ubicación del caché a utilizar. Esto podría ser el directorio para un caché de sistema de archivos, una pareja host y puerto para un servidor de memoria caché o un nombre identificativo para un caché de memoria local. Por ejemplo:
CACHES = {
"default": {
"BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
"LOCATION": "/var/tmp/django_cache",
}
}
OPCIONES¶Predeterminado: None
Parámetros adicionales para pasar al backend del caché. Los parámetros disponibles varían según el backend del caché que estés utilizando.
Puedes encontrar información sobre los parámetros disponibles en la documentación de argumentos del caché. Para obtener más información, consulta la documentación propia de tu módulo backend.
TIEMPO DE CADUCIDAD¶Predeterminado: 300
El número de segundos antes de que una entrada del caché se considere caducada. Si el valor de esta configuración es None, las entradas del caché no expirarán. Un valor de 0 provoca que las claves expiren inmediatamente (efectivamente «no cachea»).
VERSIÓN¶Default: 1
La versión por defecto del número de la caché para las claves generadas por el servidor Django.
Consulte la documentación sobre caché para obtener más información.
CACHE_MIDDLEWARE_ALIAS¶Default: 'default'
La conexión de caché a utilizar para el middleware de caché.
CACHE_MIDDLEWARE_KEY_PREFIX¶Por defecto: '' (cadena vacía)
Una cadena que se prefijará a las claves de la caché generadas por el middleware de caché. Este prefijo se combina con la configuración KEY_PREFIX; no la reemplaza.
Consulte Marco de caché de Django.
CACHE_MIDDLEWARE_SECONDS¶Default: 600
La cantidad de segundos por defecto para cachear una página mediante el middleware de caché cache middleware.
Consulte Marco de caché de Django.
CSRF_USE_SESSIONS¶Predeterminado: False
¿Almacenar el token CSRF en la sesión del usuario en lugar de en una cookie? Requiere el uso de django.contrib.sessions.
Almacenar el token CSRF en una cookie (por defecto de Django) es seguro, pero almacenarlo en la sesión es una práctica común en otros frameworks web y por lo tanto a veces se exige por parte de los auditores de seguridad.
Dado que las vistas de errores predeterminadas (vistas de error) requieren el token CSRF, SessionMiddleware debe aparecer en MIDDLEWARE antes de cualquier middleware que pueda levantar una excepción para desencadenar una vista de error (como PermissionDenied) si se está utilizando CSRF_USE_SESSIONS. Consulte ordenación de middleware.
CSRF_FAILURE_VIEW¶Por defecto: 'django.views.csrf.csrf_failure'
Una ruta punto-dotiada a la función de vista que se utilizará cuando una solicitud entrante es rechazada por la protección CSRF. La función debe tener este formato:
def csrf_failure(request, reason=""): ...
donde reason es un mensaje corto (intencionado para desarrolladores o registro, no para usuarios finales) que indica el motivo por el cual se rechazó la solicitud. Debe devolver una HttpResponseForbidden.
django.views.csrf.csrf_failure() acepta un parámetro adicional template_name que tiene como valor predeterminado '403_csrf.html'. Si existe un template con ese nombre, se utilizará para renderizar la página.
CSRF_HEADER_NAME¶Default: 'HTTP_X_CSRFTOKEN'
El nombre del encabezado de solicitud utilizado para la autenticación CSRF.
Al igual que otros encabezados HTTP en request.META, el nombre del encabezado recibido desde el servidor se normaliza convirtiendo todos los caracteres a mayúsculas, reemplazando cualquier guion con subrayados y agregando un prefijo 'HTTP_' al nombre. Por ejemplo, si tu cliente envía un encabezado 'X-XSRF-TOKEN', la configuración debe ser 'HTTP_X_XSRF_TOKEN'.
CSRF_TRUSTED_ORIGINS¶Default: [] (Lista vacía)
Una lista de orígenes confiados para solicitudes peligrosas (por ejemplo, POST).
Para solicitudes que incluyen el encabezado Origin, la protección CSRF de Django requiere que ese encabezado coincida con el origen presente en el encabezado Host.
Para una solicitud peligrosa segura que no incluye el encabezado Origin, la solicitud debe tener un encabezado Referer que coincida con el origen presente en el encabezado Host.
Estos controles previenen, por ejemplo, una solicitud POST desde subdomain.example.com de tener éxito contra api.example.com. Si necesitas solicitudes peligrosas entre orígenes, continuando con el ejemplo, agrega 'https://subdomain.example.com' a esta lista (y/o http://... si las solicitudes provienen de una página no segura).
La configuración también admite subdominios, por lo que podrías agregar 'https://*.example.com', por ejemplo, para permitir el acceso desde todos los subdominios de example.com.
DATABASES¶Default: {} (Diccionario vacío)
Un diccionario que contiene las configuraciones para todas las bases de datos a utilizar con Django. Es un diccionario anidado cuyos contenidos mapean una alias de base de datos a un diccionario que contiene las opciones para una base de datos individual.
La configuración de la DATABASES debe configurar una base de datos por defecto; también se pueden especificar cualquier número adicional de bases de datos.
El archivo de configuración más simple es para un setup de una sola base de datos utilizando SQLite. Esto se puede configurar utilizando lo siguiente:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": "mydatabase",
}
}
Al conectar a otros backends de bases de datos, como MariaDB, MySQL, Oracle o PostgreSQL, serán necesarios parámetros adicionales de conexión. Consulte la configuración de ENGINE para especificar otros tipos de base de datos. El siguiente ejemplo es para PostgreSQL:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "mydatabase",
"USER": "mydatabaseuser",
"PASSWORD": "mypassword",
"HOST": "127.0.0.1",
"PORT": "5432",
}
}
Las siguientes opciones internas que pueden requerirse para configuraciones más complejas están disponibles:
ATOMIC_REQUESTS¶Predeterminado: False
Establece esto a True para envolver cada vista en una transacción en esta base de datos. Consulte Asociar transacciones con solicitudes HTTP.
AUTOCOMMIT¶Predeterminado: True
Establece esto a False si deseas desactivar la gestión de transacciones de Django y implementar tu propia.
ENGINE¶Por defecto: '' (cadena vacía)
El backend de base de datos a utilizar. Los backends de base de datos integrados son:
django.db.backends.postgresql
django.db.backends.mysql
django.db.backends.sqlite3
django.db.backends.oracle
Puedes utilizar un motor de base de datos que no viene incluido con Django estableciendo ENGINE en una ruta completa (es decir, mypackage.backends.whatever).
HOST`¶Por defecto: '' (cadena vacía)
Cuál de los hosts utilizar al conectar a la base de datos. Una cadena vacía significa localhost. No se utiliza con SQLite.
Si este valor comienza con una barra diagonal hacia adelante (“/”) y estás utilizando MySQL, MySQL se conectará mediante un socket Unix al socket especificado. Por ejemplo:
"HOST": "/var/run/mysql"
Si estás utilizando MySQL y este valor no comienza con una barra diagonal hacia adelante, entonces se asume que este valor es el host.
Si estás utilizando PostgreSQL, por defecto (una HOST vacía), la conexión a la base de datos se realiza mediante sockets del dominio UNIX (“líneas locales” en pg_hba.conf). Si tu socket del dominio UNIX no está en la ubicación estándar, utiliza el mismo valor de unix_socket_directory desde postgresql.conf. Si deseas conectar a través de sockets TCP, establece HOST en “localhost” o “127.0.0.1” (“líneas host” en pg_hba.conf). En Windows, siempre debes definir HOST, ya que los sockets del dominio UNIX no están disponibles.
NAME¶Por defecto: '' (cadena vacía)
El nombre de la base de datos a utilizar. Para SQLite, es el camino completo al archivo de la base de datos. Al especificar el camino, siempre utiliza slashes hacia adelante, incluso en Windows (por ejemplo C:/homes/user/mysite/sqlite3.db).
CONN_MAX_AGE¶Predeterminado: 0
La vida de una conexión a la base de datos, como un entero de segundos. Utiliza 0 para cerrar las conexiones a la base de datos al final de cada solicitud — comportamiento histórico de Django — y None para conexiones persistentes sin límite:ref:conexiones persistente a la base de datos <persistent-database-connections>.
CONN_HEALTH_CHECKS¶Predeterminado: False
Si se establece en True, las conexiones a la base de datos existentes persistente se verificarán antes de reutilizarlas en cada solicitud que accede a la base de datos. Si falla la verificación, la conexión se reestablecerá sin fallar la solicitud cuando la conexión ya no esté disponible pero el servidor de la base de datos está listo para aceptar y servir nuevas conexiones (por ejemplo después del reinicio del servidor de la base de datos que cierra las conexiones existentes).
OPCIONES¶Default: {} (Diccionario vacío)
Parámetros adicionales para utilizar al conectarse a la base de datos. Los parámetros disponibles varían según el backend de tu base de datos.
Algunas informaciones sobre los parámetros disponibles se pueden encontrar en la documentación del Backend de bases de datos . Para más información, consulta la documentación propia de tu módulo de backend.
CONTRASEÑA¶Por defecto: '' (cadena vacía)
La contraseña a utilizar al conectar a la base de datos. No se utiliza con SQLite.
PUERTO¶Por defecto: '' (cadena vacía)
El puerto a utilizar al conectar a la base de datos. Una cadena vacía significa el puerto por defecto. No se utiliza con SQLite.
ZONA HORARIA¶Predeterminado: None
Una cadena que representa la zona horaria para esta conexión a la base de datos o None. Esta opción interna del parámetro DATABASES acepta los mismos valores que el parámetro general TIME_ZONE.
Cuando USE_TZ es True, leer fechas y horas desde la base de datos devuelve fechas y horas conscientes con la zona horaria establecida en este valor si no es None, o UTC en caso contrario.
Cuando USE_TZ es False, es un error establecer esta opción.
Si el motor de base de datos no admite zonas horarias (por ejemplo, SQLite, MySQL, Oracle), Django lee y escribe fechas y horas en la hora local según esta opción si está configurada o en UTC si no lo está.
Cambiar la zona horaria de la conexión cambia cómo se leen y escriben las fechas y horas en la base de datos.
Si Django gestiona la base de datos y no tienes una razón fuerte para hacerlo de otra manera, debes dejar esta opción sin establecer. Es mejor almacenar fechas y horas en UTC porque evita fechas y horas ambiguas o inexistentes durante los cambios de horario de verano. Además, recibir fechas y horas en UTC mantiene la aritmética de fechas y horas simple — no hay necesidad de considerar posibles cambios de desplazamiento sobre una transición DST.
Si estás conectado a una base de datos de terceros que almacena fechas y horas en un tiempo local en lugar de UTC, entonces debes establecer esta opción con el huso horario adecuado. De manera similar, si Django gestiona la base de datos pero sistemas de terceros se conectan a la misma base de datos y esperan encontrar fechas y horas en tiempo local, entonces debes establecer esta opción.
Si el backend de la base de datos admite husos horarios (por ejemplo, PostgreSQL), entonces el huso horario de la conexión a la base de datos se establece con este valor.
Aunque establecer la opción TIME_ZONE es muy raro que sea necesario, hay situaciones en las que se vuelve necesaria. Específicamente, se recomienda coincidir con el huso horario general TIME_ZONE cuando se tratan consultas crudas involucrando funciones de fecha/hora como la de PostgreSQL date_trunc() o generate_series(), especialmente cuando se generan series basadas en tiempo que transcurren los ahorros de energía.
Este valor puede cambiarse en cualquier momento, la base de datos manejará la conversión de fechas y horas al huso horario configurado.
Sin embargo, esto tiene un lado negativo: recibir todas las fechas y horas en tiempo local hace que la aritmética de fechas y horas sea más complicada — debes tener en cuenta posibles cambios de desplazamiento sobre transiciones DST.
Considera convertir a tiempo local explícitamente con AT TIME ZONE en consultas SQL crudas en lugar de establecer la opción TIME_ZONE.
DISABLE_SERVER_SIDE_CURSORS¶Predeterminado: False
Establece esto a True si deseas deshabilitar el uso de cursor server-side con QuerySet.iterator(). Transaction pooling and server-side cursors describe el caso de uso.
Esta es una configuración específica de PostgreSQL.
USUARIO¶Por defecto: '' (cadena vacía)
El nombre de usuario a utilizar al conectarse a la base de datos. No se utiliza con SQLite.
PRUEBA¶Default: {} (Diccionario vacío)
Un diccionario de configuración para bases de datos de prueba; para obtener más detalles sobre la creación y uso de bases de datos de prueba, consulte la-base-de-datos-de-prueba.
Aquí tienes un ejemplo con una configuración de base de datos de prueba:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.postgresql",
"USER": "mydatabaseuser",
"NAME": "mydatabase",
"TEST": {
"NAME": "mytestdatabase",
},
},
}
Las siguientes claves en el diccionario PRUEBA están disponibles:
CODIFICACIÓN¶Predeterminado: None
El conjunto de caracteres utilizado para crear la base de datos de prueba. El valor de esta cadena se pasa directamente al motor de base de datos, por lo que su formato es específico del backend.
Soportado por los backends PostgreSQL (postgresql) y MySQL (mysql).
ORDENACIÓN¶Predeterminado: None
El orden de collación a utilizar al crear la base de datos de prueba. Este valor se pasa directamente al backend, por lo que su formato es específico del backend.
Solo está soportado para el backend mysql (consulte el manual de MySQL para detalles).
DEPENDENCIAS¶Por defecto: ['default'], para todas las bases de datos excepto la default, que no tiene dependencias.
Las dependencias del orden de creación de la base de datos. Consulte la documentación sobre el control del orden de creación de las bases de datos de prueba para detalles.
MIGRATE¶Predeterminado: True
Al establecerlo en False, las migraciones no se ejecutarán al crear la base de datos de prueba. Esto es similar a establecer None como valor en MIGRATION_MODULES, pero para todas las aplicaciones.
ESPEJO¶Predeterminado: None
El alias de la base de datos que esta base de datos debe reflejar durante la prueba. Depende de transacciones y por lo tanto debe usarse dentro de TransactionTestCase en lugar de TestCase.
Esta configuración existe para permitir la prueba de configuraciones primaria/replica (referidas como maestro/esclavo por algunas bases de datos) de múltiples bases de datos. Consulte la documentación sobre la prueba de configuraciones primaria/replica para detalles.
NAME¶Predeterminado: None
El nombre de la base de datos a utilizar cuando se ejecuta el conjunto de pruebas.
Si se utiliza el valor por defecto (None) con el motor de bases de datos SQLite, las pruebas usarán una base de datos residente en memoria. Para todos los demás motores de bases de datos, la base de datos de prueba utilizará el nombre 'test_' + DATABASE_NAME.
Consultar: la-base-de-datos-de-prueba.
TEMPLATE¶Esta es una configuración específica de PostgreSQL.
El nombre de un template (por ejemplo, 'template0') desde el que crear la base de datos de prueba.
CREATE_DB¶Predeterminado: True
Esta es una configuración específica del motor Oracle.
Si se establece en False, las tablas de espacios de almacenamiento de pruebas no se crearán automáticamente al principio de las pruebas ni se eliminarán al final.
CREATE_USER¶Predeterminado: True
Esta es una configuración específica del motor Oracle.
Si se establece en False, el usuario de prueba no se creará automáticamente al principio de las pruebas y no se eliminará al final.
USUARIO¶Predeterminado: None
Esta es una configuración específica del motor Oracle.
El username a utilizar al conectar con la base de datos Oracle que se usará cuando se ejecuten las pruebas. Si no se proporciona, Django utilizará 'test_' + USER.
CONTRASEÑA¶Predeterminado: None
Esta es una configuración específica del motor Oracle.
La contraseña a utilizar al conectar con la base de datos Oracle que se usará cuando se ejecuten las pruebas. Si no se proporciona, Django generará una contraseña aleatoria.
Predeterminado: False
Esta es una configuración específica del motor Oracle.
Si se establece en True, se utilizarán tablespaces Oracle Managed Files (OMF). DATAFILE y DATAFILE_TMP serán ignorados.
Predeterminado: None
Esta es una configuración específica del motor Oracle.
El nombre del espacio de tablas que se usará cuando se ejecuten las pruebas. Si no se proporciona, Django utilizará 'test_' + USER.
Predeterminado: None
Esta es una configuración específica del motor Oracle.
El nombre del espacio de tablas temporal que se usará cuando se ejecuten las pruebas. Si no se proporciona, Django utilizará 'test_' + USER + '_temp'.
Predeterminado: None
Esta es una configuración específica del motor Oracle.
El nombre del archivo de datos a usar para el TBLSPACE. Si no se proporciona, Django utilizará TBLSPACE + “.dbf”.
ARCHIVO_TEMPORAL¶Predeterminado: None
Esta es una configuración específica del motor Oracle.
El nombre del archivo de datos a utilizar para el TBLSPACE_TMP. Si no se proporciona, Django utilizará TBLSPACE_TMP + '.dbf'.
MAXSIZE_DATAFILE¶Predeterminado: '500M'
Esta es una configuración específica del motor Oracle.
El tamaño máximo que está permitido que crezca el ARCHIVO_DATAFILE.
MAXSIZE_ARCHIVO_TEMPORAL¶Predeterminado: '500M'
Esta es una configuración específica del motor Oracle.
El tamaño máximo que está permitido que crezca el ARCHIVO_TEMPORAL.
TAMANO_ARCHIVO¶Predeterminado: '50M'
Esta es una configuración específica del motor Oracle.
El tamaño inicial del ARCHIVO_DATAFILE.
DATAFILE_TMP_SIZE¶Predeterminado: '50M'
Esta es una configuración específica del motor Oracle.
El tamaño inicial del DATAFILE_TMP.
DATAFILE_EXTSIZE¶Por defecto: '25M'
Esta es una configuración específica del motor Oracle.
La cantidad por la que se extiende el DATAFILE cuando es necesario más espacio.
DATAFILE_TMP_EXTSIZE¶Por defecto: '25M'
Esta es una configuración específica del motor Oracle.
La cantidad por la que se extiende el DATAFILE_TMP cuando es necesario más espacio.
DATA_UPLOAD_MAX_MEMORY_SIZE¶Por defecto: 2621440 (es decir, 2.5 MB).
El tamaño máximo en bytes que puede ser un cuerpo de solicitud antes de que se levante una SuspiciousOperation (RequestDataTooBig) . La comprobación se realiza cuando se accede a request.body o request.POST y se calcula contra el tamaño total de la solicitud excluyendo cualquier datos de subida de archivo. Puedes establecer esto en None para deshabilitar la comprobación. Las aplicaciones que esperan recibir formularios de post grandes deben ajustar esta configuración.
La cantidad de datos de solicitud está correlacionada con la cantidad de memoria necesaria para procesar la solicitud y poblar los diccionarios GET y POST. Las solicitudes grandes podrían usarse como un vector de ataque de denegación de servicio si no se controlan. Dado que los servidores web no suelen realizar inspecciones de solicitudes profundas, no es posible realizar una comprobación similar a ese nivel.
Consulte también FILE_UPLOAD_MAX_MEMORY_SIZE.
DATA_UPLOAD_MAX_NUMBER_FIELDS¶Predeterminado: 1000
La cantidad máxima de parámetros que pueden recibirse a través de GET o POST antes de que se levante un SuspiciousOperation (TooManyFields) es el valor de esta configuración. Puede establecerlo en None para deshabilitar la comprobación. Las aplicaciones que esperan recibir un número anormalmente grande de campos de formulario deben ajustar este parámetro.
La cantidad de parámetros de solicitud está correlacionada con la cantidad de tiempo necesario para procesar la solicitud y poblar los diccionarios GET y POST. Las solicitudes grandes podrían usarse como un vector de ataque de denegación de servicio si no se controlan. Dado que los servidores web no suelen realizar inspecciones de solicitudes profundas, no es posible realizar una comprobación similar a ese nivel.
DATA_UPLOAD_MAX_NUMBER_FILES¶Predeterminado: 100
La cantidad máxima de archivos que pueden recibirse a través de POST en una solicitud codificada multipart/form-data antes de que se levante un SuspiciousOperation (TooManyFiles) es el valor de esta configuración. Puede establecerlo en None para deshabilitar la comprobación. Las aplicaciones que esperan recibir un número anormalmente grande de campos de archivo deben ajustar este parámetro.
La cantidad de archivos aceptados está correlacionada con la cantidad de tiempo y memoria necesaria para procesar la solicitud. Las solicitudes grandes podrían usarse como un vector de ataque de denegación de servicio si no se controlan. Dado que los servidores web no suelen realizar inspecciones de solicitudes profundas, no es posible realizar una comprobación similar a ese nivel.
Default: [] (Lista vacía)
La lista de routers que se utilizarán para determinar qué base de datos usar cuando realizar una consulta a la base de datos.
Ver la documentación sobre rutas de base de datos automáticas en configuraciones de múltiples bases de datos.
Por defecto: 'N j, Y' (p. ej. Feb. 4, 2003)
La formación por defecto para mostrar campos de fecha en cualquier parte del sistema. Tenga en cuenta que la forma determinada por el idioma tiene mayor precedencia y se aplicará en su lugar. Consulte cadenas de formato de fecha permitidas.
Ver también DATETIME_FORMAT, TIME_FORMAT y SHORT_DATE_FORMAT.
Predeterminado:
[
"%Y-%m-%d", # '2006-10-25'
"%m/%d/%Y", # '10/25/2006'
"%m/%d/%y", # '10/25/06'
"%b %d %Y", # 'Oct 25 2006'
"%b %d, %Y", # 'Oct 25, 2006'
"%d %b %Y", # '25 Oct 2006'
"%d %b, %Y", # '25 Oct, 2006'
"%B %d %Y", # 'October 25 2006'
"%B %d, %Y", # 'October 25, 2006'
"%d %B %Y", # '25 October 2006'
"%d %B, %Y", # '25 October, 2006'
]
Una lista de formatos que se aceptarán cuando se ingrese datos en un campo de fecha. Se intentará utilizar los formatos en orden, utilizando el primero válido. Ten en cuenta que estas cadenas de formato utilizan la sintaxis del módulo datetime de Python, no las cadenas de formato del filtro de plantilla date.
El formato determinado por la configuración de localización tiene mayor precedencia y se aplicará en su lugar.
Ver también DATETIME_INPUT_FORMATS y TIME_INPUT_FORMATS.
Por defecto: 'N j, Y, P' (por ejemplo, feb. 4, 2003, 4 p.m.)
La formación por defecto para mostrar campos de fecha y hora en cualquier parte del sistema. Tenga en cuenta que la forma determinada por el idioma tiene mayor precedencia y se aplicará en su lugar. Consulte cadenas de formato de fecha permitidas.
Ver también FORMATO_FECHA, FORMATO_HORA y FORMATO_FECHA_Y_HORA_CORTA.
Predeterminado:
[
"%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59'
"%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200'
"%Y-%m-%d %H:%M", # '2006-10-25 14:30'
"%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59'
"%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200'
"%m/%d/%Y %H:%M", # '10/25/2006 14:30'
"%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59'
"%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200'
"%m/%d/%y %H:%M", # '10/25/06 14:30'
]
Una lista de formatos que se aceptarán cuando se ingrese datos en un campo de fecha y hora. Se intentará utilizar los formatos en el orden en que aparecen, utilizando el primero válido. Ten en cuenta que estas cadenas de formato utilizan la sintaxis del módulo datetime de Python, no las cadenas de formato desde el filtro de plantilla date. Los formatos de fecha solo se incluyen como campos de fecha y hora ya que estos intentarán utilizar DATE_INPUT_FORMATS en última instancia.
El formato determinado por la configuración de localización tiene mayor precedencia y se aplicará en su lugar.
Ver también FORMATOS DE ENTRADA DE FECHA y FORMATOS DE ENTRADA DE HORA.
DEBUG¶Predeterminado: False
Un booleano que activa/desactiva el modo de depuración.
No desplegues un sitio en producción con DEBUG activado.
Una de las características principales del modo depuración es la visualización de páginas de errores detalladas. Si tu aplicación lanza una excepción cuando DEBUG está en True, Django mostrará un seguimiento detallado, incluyendo una gran cantidad de metadatos sobre tu entorno, como todos los ajustes de configuración de Django actualmente definidos (de settings.py).
Como medida de seguridad, Django no incluirá ajustes que podrían ser sensibles, como SECRET_KEY. Específicamente, excluirá cualquier ajuste cuyo nombre incluya alguna de las siguientes:
'API'
'KEY'
'PASS'
'SECRET'
'SIGNATURE'
'TOKEN'
Nota que estos son coincidencias parciales. 'PASS' también coincidiría con PASSWORD, al igual que 'TOKEN' coincidiría con TOKENIZED y así sucesivamente.
Sin embargo, todavía hay siempre secciones de tu salida de depuración que son inapropiadas para el consumo público. Los caminos de archivo, opciones de configuración y similares proporcionan a los atacantes información adicional sobre tu servidor.
It is also important to remember that when running with DEBUG
turned on, Django will remember every SQL query it executes. This is useful
when you’re debugging, but it’ll rapidly consume memory on a production server.
Finalmente, si DEBUG está False, también necesitas configurar correctamente la ALLOWED_HOSTS de configuración. Si no lo haces, todas las solicitudes se devolverán como «Bad Request (400)».
Nota
El archivo de configuración por defecto settings.py creado por django-admin startproject establece DEBUG = True para conveniencia.
DEBUG_PROPAGATE_EXCEPTIONS¶Predeterminado: False
Si se establece en True, el manejo de excepciones de Django de funciones de vistas (handler500, o la vista de depuración si DEBUG está True) y la registro de 500 respuestas (django.request) se saltan y las excepciones propagan hacia arriba.
Esto puede ser útil para algunas configuraciones de prueba. No debería usarse en un sitio en vivo a menos que desees que tu servidor web (en lugar de Django) genere respuestas «Internal Server Error». En ese caso, asegúrate de que tu servidor no muestre la pila de llamadas o información sensible en la respuesta.
DECIMAL_SEPARATOR¶Predeterminado: '.' (Punto)
Separador decimal predeterminado utilizado al formatear números decimales.
Ten en cuenta que el formato determinado por la localización tiene mayor precedencia y se aplicará en su lugar.
See also NUMBER_GROUPING, THOUSAND_SEPARATOR y USE_THOUSAND_SEPARATOR.
DEFAULT_AUTO_FIELD¶Predeterminado: ``”:class:`django.db.models.AutoField``”`
Tipo de campo primario por defecto para utilizar en modelos que no tienen un campo con primary_key=True.
Default: 'utf-8'
Característica de codificación por defecto para utilizar en todos los objetos HttpResponse, si no se especifica manualmente un tipo MIME. Utilizado al construir el encabezado Content-Type.
Default: 'django.views.debug.ExceptionReporter'
Clase de informe de excepción por defecto que se utilizará si ninguna ha sido asignada a la instancia de HttpRequest todavía. Consulta informes-de-errores-personalizados.
Default: 'django.views.debug.SafeExceptionReporterFilter'
Clase de filtro para informes de excepciones por defecto que se utiliza si no ha sido asignada ninguna a la instancia de HttpRequest aún. Consulta Filtrado de informes de errores.
Predeterminado: webmaster@localhost
Dirección de correo electrónico predeterminada para la correspondencia automática del administrador (o administradores) del sitio. Esta dirección se utiliza en el encabezado From: de los correos electrónicos salientes y puede tener cualquier formato válido en el protocolo de envío de correos electrónicos elegido.
Esto no afecta a los mensajes de error enviados a ADMINS y MANAGERS. Consulte CORREO_DE_SERVIDOR para eso.
Por defecto: '' (cadena vacía)
Espacio de nombres predeterminado para utilizar en los índices de campos que no especifican uno, si el backend lo admite (consulte Espacios de tablas).
Por defecto: '' (cadena vacía)
Espacio de nombres predeterminado para utilizar en modelos que no especifican uno, si el backend lo admite (consulte Espacios de tablas).
Default: [] (Lista vacía)
Lista de objetos de expresiones regulares compilados que representan cadenas de User-Agent que no están permitidas para visitar ninguna página, de manera general. Utilice esto para bots/crawlers. Esto solo se utiliza si CommonMiddleware está instalado (consulte Middleware).
EMAIL_BACKEND¶Predeterminado: 'django.core.mail.backends.smtp.EmailBackend``”`
El backend a utilizar para enviar correos electrónicos. Para la lista de backends disponibles, ver Los backends de correo electrónico.
EMAIL_FILE_PATH¶Predeterminado: No definido
La carpeta utilizada por el backend de correo electrónico de archivo (file email backend) para almacenar archivos de salida.
EMAIL_HOST¶Predeterminado: 'localhost'
El host a utilizar para enviar correos electrónicos.
Ver también EMAIL_PORT.
CONTRASEÑA_DE_HOST_EMAIL¶Por defecto: '' (cadena vacía)
La contraseña a utilizar para el servidor SMTP definido en EMAIL_HOST. Esta configuración se utiliza conjuntamente con EMAIL_HOST_USER al autenticarse en el servidor SMTP. Si cualquiera de estas configuraciones está vacía, Django no intentará la autenticación.
Consulte también EMAIL_HOST_USER.
CONTRASEÑA_DE_HOST_EMAIL¶Por defecto: '' (cadena vacía)
El nombre de usuario a utilizar para el servidor SMTP definido en EMAIL_HOST. Si está vacío, Django no intentará la autenticación.
Consulte también CONTRASEÑA_DE_HOST_EMAIL.
PUERTO_EMAIL¶Predeterminado: 25
El puerto a utilizar para el servidor SMTP definido en EMAIL_HOST.
PREPOSICIÓN_DE_ASUNTO_EMAIL¶Default: '[Django] '
Prefijo de línea de asunto para los mensajes de correo electrónico enviados con django.core.mail.mail_admins o django.core.mail.mail_managers. Probablemente querrás incluir el espacio en blanco al final.
EMAIL_USE_LOCALTIME¶Predeterminado: False
¿Enviar la cabecera SMTP Date de los mensajes de correo electrónico en la zona horaria local (True) o en UTC (False)?
EMAIL_USE_TLS¶Predeterminado: False
¿Usar una conexión TLS (segura) cuando se habla con el servidor SMTP? Esto se utiliza para conexiones TLS explícitas, generalmente en el puerto 587. Si está experimentando conexiones que se quedan colgadas, consulte la configuración de TLS implícita EMAIL_USE_SSL.
EMAIL_USE_SSL¶Predeterminado: False
¿Usar una conexión TLS (segura) implícita cuando se habla con el servidor SMTP? En la mayoría de la documentación de correo electrónico, este tipo de conexión TLS se denomina SSL. Se utiliza generalmente en el puerto 465. Si está experimentando problemas, consulte la configuración de TLS explícita EMAIL_USE_TLS.
Ten en cuenta que EMAIL_USE_TLS/EMAIL_USE_SSL son mutuamente excluyentes, por lo que solo establezca una de esas configuraciones a True.
EMAIL_SSL_CERTFILE¶Predeterminado: None
Si EMAIL_USE_SSL o EMAIL_USE_TLS es True y la conexión segura al servidor SMTP requiere autenticación del cliente, utiliza este ajuste para especificar el camino a un archivo de cadena de certificados PEM formateados, que debe usarse conjuntamente con EMAIL_SSL_KEYFILE.
EMAIL_SSL_CERTFILE no debe usarse con un servidor de certificado autofirmado o un certificado de una autoridad de certificación privada (CA). En tales casos, el certificado del servidor (o el certificado raíz de la CA privada) deben instalarse en el conjunto de certificados CA del sistema. Esto se puede hacer siguiendo instrucciones específicas de plataforma para instalar un certificado raíz CA o utilizando las variables de entorno OpenSSL SSL_CERT_FILE o SSL_CERT_DIR para especificar un conjunto de certificados personalizado (si no es posible o deseable modificar el conjunto de certificados del sistema).
Para escenarios más complejos, el servidor SMTP EmailBackend se puede sobrescribir para agregar certificados raíz a su ssl_context utilizando la función ssl.SSLContext.load_verify_locations().
EMAIL_SSL_KEYFILE¶Predeterminado: None
Si EMAIL_USE_SSL o EMAIL_USE_TLS es True, puedes especificar opcionalmente el camino a un archivo de clave privada PEM formateado para la autenticación del cliente de la conexión SSL junto con EMAIL_SSL_CERTFILE.
Ten en cuenta que establecer EMAIL_SSL_CERTFILE y EMAIL_SSL_KEYFILE no resulta en ninguna comprobación de certificado. Se pasan a la conexión SSL subyacente. Consulte la documentación del método de Python python:ssl.SSLContext.wrap_socket para obtener detalles sobre cómo se manejan el archivo de cadena de certificados y el archivo de clave privada.
EMAIL_TIMEOUT¶Predeterminado: None
Especifica un tiempo de espera en segundos para operaciones bloqueantes como la intento de conexión.
FILE_UPLOAD_HANDLERS¶Predeterminado:
[
"django.core.files.uploadhandler.MemoryFileUploadHandler",
"django.core.files.uploadhandler.TemporaryFileUploadHandler",
]
Una lista de manipuladores para usar para subir archivos. Cambiar este ajuste permite una personalización completa – incluso reemplazo – del proceso de carga de Django.
Ver Gestión de archivos para detalles.
Por defecto: 2621440 (es decir, 2.5 MB).
El tamaño máximo (en bytes) que tendrá un archivo subido antes de ser enviado al sistema de archivos. Consulta la sección sobre archivos para obtener más detalles.
Ver también DATA_UPLOAD_MAX_MEMORY_SIZE.
Predeterminado: None
El modo numérico para aplicar a directorios creados en el proceso de subir archivos.
Esta configuración también determina los permisos por defecto para los directorios de archivos estáticos recopilados cuando se utiliza el comando de gestión collectstatic. Consulte collectstatic para obtener detalles sobre cómo sobrescribirlo.
Este valor refleja la funcionalidad y las limitaciones del parámetro FILE_UPLOAD_PERMISSIONS.
FILE_UPLOAD_PERMISSIONS`¶Por defecto: 0o644
La traducción de los textos es la siguiente:
Si None, obtendrás comportamiento dependiente del sistema operativo. En la mayoría de las plataformas, los archivos temporales tendrán un modo de 0o600 y los archivos guardados desde memoria se guardarán utilizando el umask estándar del sistema.
Por razones de seguridad, estas permisos no se aplican a los archivos temporales almacenados en FILE_UPLOAD_TEMP_DIR.
Esta configuración también determina las permisos por defecto para los archivos estáticos recopilados cuando se utiliza el comando de administración collectstatic. Consulte collectstatic para obtener detalles sobre cómo sobrescribirlo.
Advertencia
Siempre antepone el modo con 0o .
Si no estás familiarizado con los modos de archivo, ten en cuenta que la prefijo 0o es muy importante: indica un número octal, que es la forma en que deben especificarse los modos. Si intentas utilizar 644, obtendrás comportamiento completamente incorrecto.
FILE_UPLOAD_TEMP_DIR¶Predeterminado: None
El directorio para almacenar datos (normalmente archivos mayores que FILE_UPLOAD_MAX_MEMORY_SIZE) temporalmente mientras se suben archivos. Si None, Django utilizará el directorio temporal estándar del sistema operativo. Por ejemplo, esto se establecerá en /tmp en sistemas operativos de estilo *nix.
Ver Gestión de archivos para detalles.
FIRST_DAY_OF_WEEK¶Predeterminado: 0 (Domingo)
Un número que representa el primer día de la semana. Esto es especialmente útil cuando se muestra un calendario. Este valor solo se utiliza cuando no se está utilizando la internacionalización del formato, o cuando no se puede encontrar un formato para la ubicación actual.
El valor debe ser un entero desde 0 hasta 6, donde 0 significa domingo, 1 significa lunes y así sucesivamente.
FIXTURE_DIRS¶Default: [] (Lista vacía)
Lista de directorios buscados para archivos de fijación , además del directorio fixtures de cada aplicación, en orden de búsqueda.
Ten en cuenta que estos caminos deben utilizar forward slashes estilo Unix, incluso en Windows.
Consulte Proporcionar datos con fijadores. y Carga de fijadores.
FORCE_SCRIPT_NAME¶Predeterminado: None
Si no es None, se utilizará como valor de la variable de entorno SCRIPT_NAME en cualquier solicitud HTTP. Esta configuración se puede utilizar para sobrescribir el valor proporcionado por el servidor de SCRIPT_NAME, que puede ser una versión reescrita del valor preferido o no estar suministrada en absoluto. También se utiliza por django.setup() para establecer la prefija de resolución de URL fuera del ciclo de solicitud/respuesta (por ejemplo, en comandos de administración y scripts independientes) para generar URLs correctas cuando FORCE_SCRIPT_NAME está proporcionado.
FORM_RENDERER¶Predeterminado: ``”:class:`django.forms.renderers.DjangoTemplates``”
La traducción de los textos es la siguiente:
FORMS_URLFIELD_ASSUME_HTTPS¶Obsoleto desde la versión 5.0.
Predeterminado: False
Establezca esta configuración transitoria a True para optar por utilizar "https" como nuevo valor predeterminado de URLField.assume_scheme durante el ciclo de lanzamiento de Django 5.x.
FORMAT_MODULE_PATH¶Predeterminado: None
Un camino completo de Python a un paquete de Python que contiene definiciones personalizadas de formato para locales del proyecto. Si no es None, Django comprobará por un archivo formats.py en el directorio denominado como la locale actual, y utilizará las formatos definidos en este archivo.
El nombre del directorio que contiene las definiciones de formato se espera que esté nombrado utilizando notación de nombre de locale, por ejemplo de, pt_BR, en_US, etc.
Por ejemplo, si FORMAT_MODULE_PATH está configurada a mysite.formats, y el idioma actual es en (inglés), Django esperará un árbol de directorios como:
mysite/
formats/
__init__.py
en/
__init__.py
formats.py
Puedes establecer esta configuración en una lista de rutas Python, por ejemplo:
FORMAT_MODULE_PATH = [
"mysite.formats",
"some_app.formats",
]
Cuando Django busca un cierto formato, buscará a través de todas las rutas Python dadas hasta encontrar un módulo que defina realmente el formato dado. Esto significa que los formatos definidos en paquetes más arriba en la lista tendrán prioridad sobre los mismos formatos en paquetes más abajo.
Los formatos disponibles son:
FORMATO_DE_FECHA
FORMATOS_DE_INGRESO_DE_FECHA
FORMATO_DE_HORA,
FORMATOS_DE_INGRESO_DE_HORA
SEPARADOR_DECIMAL
PRIMER_DÍA_DE_LA_SEMANA
FORMATO_DE_MES_Y_DÍA
NÚMERO_DE_GRUPADO
FORMATO DE FECHA CORTA
FORMATO DE FECHA Y HORA CORTA
SEPARADOR DE MILLE
FORMATO DE HORA
FORMATOS DE ENTRADA DE HORA
FORMATO DE AÑO Y MES
URLS IGNORABLES 404¶Default: [] (Lista vacía)
Lista de objetos de expresiones regulares compiladas que describen URLs que deben ignorarse al informar errores HTTP 404 por correo electrónico (consulte How to manage error reporting
Cómo gestionar el informe de errores.). Las expresiones regulares se comparan con los paths completos del pedido (incluyendo la cadena de consulta, si hay alguna). Utilice esto si su sitio no proporciona un archivo solicitado común como favicon.ico o robots.txt.
Esto se utiliza solo si está habilitada BrokenLinkEmailsMiddleware (consulte Middleware).
Default: [] (Lista vacía)
Una lista de cadenas que designan todas las aplicaciones habilitadas en esta instalación de Django. Cada cadena debe ser un camino de Python puntoado hacia:
una clase de configuración de aplicación (preferible), o
un paquete que contiene una aplicación.
Más información sobre las configuraciones de aplicación.
Utilice el registro de aplicaciones para introspección
Tu código nunca debe acceder a INSTALLED_APPS directamente. Use en su lugar django.apps.apps .
Los nombres y etiquetas de las aplicaciones deben ser únicos en INSTALLED_APPS
El nombre de la aplicación names — el camino de Python puntoado hacia el paquete de la aplicación — debe ser único. No existe forma de incluir la misma aplicación dos veces, a menos que duplique su código bajo otro nombre.
La etiqueta de la aplicación labels — por defecto el último parte del nombre — también debe ser única. Por ejemplo, no se puede incluir tanto django.contrib.auth como myproject.auth. Sin embargo, puedes relabelar una aplicación con una configuración personalizada que defina un diferente label.
Estos reglas se aplican sin importar si la configuración de las aplicaciones en INSTALLED_APPS hace referencia a clases de configuración de aplicación o paquetes de aplicación.
Cuando varias aplicaciones proporcionan versiones diferentes del mismo recurso (plantilla, archivo estático, comando de administración, traducción), la aplicación que se lista primero en INSTALLED_APPS tiene prioridad.
INTERNAL_IPS¶Default: [] (Lista vacía)
Una lista de direcciones IP, como cadenas, que:
Permiten al procesador de contexto debug() agregar algunas variables al contexto del template.
Pueden utilizar los marcadores de libro de notas admindocs bookmarklets incluso si no se ha iniciado sesión como usuario de personal de atención.
Están marcadas como «internas» (a diferencia de «externas») en los correos electrónicos del manejador de correo electrónico AdminEmailHandler.
LANGUAGE_CODE¶Predeterminado: 'en-us'
Una cadena que representa el código de idioma para esta instalación. Esto debería estar en formato estándar de identificador de idioma. Por ejemplo, el inglés de EE. UU. es "en-us". Consulte también la lista de identificadores de idiomas y Internacionalización y localización.
Sirve tres propósitos:
Si el middleware de localización no está en uso, decide qué traducción se sirve a todos los usuarios.
Si el middleware de localización está activo, proporciona un idioma de fallback en caso de que el idioma preferido del usuario no pueda determinarse o no esté soportado por la web. También proporciona la traducción de fallback cuando una traducción para una literal dada no existe para el idioma preferido del usuario.
Si se deshabilita explícitamente la localización mediante el filtro unlocalize o el etiqueta {% localize off %}, proporciona formatos de localización de fallback que se aplicarán en su lugar. Consulte controlling localization in templates para obtener más detalles.
Consulte Cómo Django descubre la preferencia del idioma para obtener más detalles.
LANGUAGES¶Valor predeterminado: Una lista de todos los idiomas disponibles. Esta lista está en constante crecimiento y incluir una copia aquí inevitablemente se volvería rápidamente obsoleta. Puedes ver la lista actual de idiomas traducidos buscando en django/conf/global_settings.py.
La lista es una lista de 2-tuplas en el formato (código de idioma, nombre del idioma) – por ejemplo, ('ja', 'Japonés'). Esto especifica qué idiomas están disponibles para la selección de idioma. Consulta Internacionalización y localización.
En general, el valor predeterminado debería ser suficiente. Solo establece esta configuración si deseas restringir la selección del idioma a un subconjunto de los idiomas proporcionados por Django.
Si defines una configuración personalizada LANGUAGES, puedes marcar los nombres de idioma como cadenas de traducción utilizando la función gettext_lazy().
Aquí tienes un ejemplo de archivo de configuración:
from django.utils.translation import gettext_lazy as _
LANGUAGES = [
("de", _("German")),
("en", _("English")),
]
LANGUAGES_BIDI¶Predeterminado: Una lista de todos los códigos de idioma escritos de derecha a izquierda. Puedes ver la lista actual de estos idiomas buscando en django/conf/global_settings.py.
La lista contiene códigos de idioma para idiomas que se escriben de derecha a izquierda.
En general, el valor predeterminado debería ser suficiente. Solo establece esta configuración si deseas restringir la selección del idioma a un subconjunto de los idiomas proporcionados por Django. Si defines una configuración personalizada LANGUAGES, la lista de idiomas bidireccionales puede contener códigos de idioma que no están habilitados en un sitio determinado.
LOCALE_PATHS¶Default: [] (Lista vacía)
Una lista de directorios donde Django busca los archivos de traducción. Consulta Cómo Django descubre las traducciones.
Ejemplo:
LOCALE_PATHS = [
"/home/www/project/common_files/locale",
"/var/local/translations/locale",
]
Django buscará dentro de cada uno de estos caminos los directorios <locale_code>/LC_MESSAGES que contienen los archivos de traducción reales.
LOGGING¶Predeterminado: Un diccionario de configuración de registro.
Una estructura de datos que contiene información de configuración. Cuando no está vacío, el contenido de esta estructura de datos se pasará como argumento al método de configuración descrito en LOGGING_CONFIG.
Entre otras cosas, la configuración de registro por defecto pasa errores de servidor HTTP 500 a un manipulador de registros de correo electrónico cuando DEBUG es False. Consulte también configurando-logging.
Puedes ver la configuración de registro por defecto buscando en django/utils/log.py.
LOGGING_CONFIG¶Por defecto: 'logging.config.dictConfig'
Una ruta a un llamable que se utilizará para configurar el registro en el proyecto Django. Puntúa hacia una instancia del método de configuración dictConfig de Python por defecto.
Si estableces LOGGING_CONFIG en None, el proceso de configuración de registro se saltará.
MANAGERS¶Default: [] (Lista vacía)
Una lista en el mismo formato que ADMINS que especifica quién debe recibir notificaciones de enlaces rotos cuando la clase BrokenLinkEmailsMiddleware está habilitada.
MEDIA_ROOT¶Por defecto: '' (cadena vacía)
Ruta absoluta del sistema de archivos al directorio que almacenará los archivos subidos por el usuario: archivos subidos por el usuario.
«/var/www/example.com/media/»
Consulta también MEDIA_URL.
Advertencia
MEDIA_ROOT y STATIC_ROOT deben tener valores diferentes. Antes de que se introdujo STATIC_ROOT, era común confiar o recurrir a MEDIA_ROOT para servir archivos estáticos; sin embargo, dado que esto puede tener implicaciones de seguridad serias, hay una verificación de validación para prevenirlo.
MEDIA_URL¶Por defecto: '' (cadena vacía)
La URL que maneja los medios servidos desde MEDIA_ROOT, utilizada para gestionar archivos almacenados. Debe terminar en una barra si se establece un valor no vacío. Necesitarás configurar estos archivos para ser servidos tanto en entornos de desarrollo como de producción.
Si deseas utilizar {{ MEDIA_URL }} en tus plantillas, agrega 'django.template.context_processors.media' en la opción 'context_processors' de TEMPLATES.
Ejemplo: "https://media.example.com/"
Advertencia
Hay riesgos de seguridad si estás aceptando contenido subido desde usuarios no confiables! Consulta el tema sobre seguridad del contenido subido por usuarios en la guía de seguridad para obtener detalles de mitigación.
Advertencia
MEDIA_URL y STATIC_URL deben tener valores diferentes. Consulta MEDIA_ROOT para más detalles.
Nota
Si MEDIA_URL es una ruta relativa, entonces se prefixará con el valor proporcionado por el servidor de SCRIPT_NAME (o / si no está configurado). Esto facilita servir una aplicación Django en un subcaminho sin agregar una configuración adicional a las configuraciones.
MIDDLEWARE¶Predeterminado: None
Una lista de middleware a utilizar. Consulta Middleware.
MIGRATION_MODULES¶Default: {} (Diccionario vacío)
Un diccionario que especifica el paquete donde se pueden encontrar los módulos de migración en una base por aplicación. El valor predeterminado de esta configuración es un diccionario vacío, pero el nombre del paquete predeterminado para los módulos de migración es migrations.
Ejemplo:
{"blog": "blog.db_migrations"}
En este caso, las migraciones pertenecientes a la aplicación blog se contienen en el paquete blog.db_migrations.
Si proporcionas el argumento app_label, makemigrations creará automáticamente el paquete si no existe.
Cuando suministras None como valor para una aplicación, Django considerará la aplicación como una aplicación sin migraciones independientemente de un módulo migrations existente. Esto se puede utilizar, por ejemplo, en un archivo de configuración de pruebas para saltarse las migraciones mientras se están realizando las pruebas (se crearán aún las tablas para los modelos de la aplicación). Para deshabilitar las migraciones para todas las aplicaciones durante las pruebas, puedes establecer el MIGRATE en False en lugar de eso. Si se utiliza MIGRATION_MODULES en tus configuraciones generales del proyecto, recuerda utilizar la opción migrate --run-syncdb si deseas crear tablas para la aplicación.
MONTH_DAY_FORMAT¶Predeterminado: 'F j'
La formación predeterminada a utilizar para los campos de fecha en las páginas de cambio del administrador Django – y, posiblemente, por otras partes del sistema – en casos en que solo se muestran el mes y el día.
Por ejemplo, cuando una página de lista de cambios Django admin está siendo filtrada por un drilldown de fecha, el encabezado para un día dado muestra el día y mes. Las diferentes localizaciones tienen formatos diferentes. Por ejemplo, el inglés estadounidense diría «enero 1,» mientras que el español podría decir «1 Enero.»
Ten en cuenta que el formato determinado por la correspondiente locale tiene mayor precedencia y se aplicará en su lugar.
Consulte cadenas de formato de fecha permitidas. Consulte también FORMATO DE FECHA, FORMATO DE HORA Y FECHA, FORMATO DE HORA y FORMATO DE AÑO Y MES.
NÚMERO DE AGREGACIÓN¶Predeterminado: 0
Número de dígitos agrupados juntos en la parte entera de un número.
El uso común es mostrar un separador de miles. Si esta configuración es 0, entonces no se aplicará ningún grupo al número. Si esta configuración es mayor que 0, entonces SEPARADOR DE MILLES se utilizará como separador entre esos grupos.
Algunas localizaciones utilizan agrupación de dígitos no uniforme, por ejemplo 10,00,00,000 en en_IN. Para este caso, puedes proporcionar una secuencia con el número de tamaños de grupo de dígitos a aplicar. El primer número define el tamaño del grupo precedente al separador decimal y cada número que sigue define el tamaño de los grupos anteriores. Si la secuencia se termina con -1, no se realizará ninguna agrupación adicional. Si la secuencia se termina con un 0, se utiliza el último tamaño de grupo para el resto del número.
Ejemplo de tupla para en_IN:
NUMBER_GROUPING = (3, 2, 0)
Ten en cuenta que el formato determinado por la localización tiene mayor precedencia y se aplicará en su lugar.
Consulte también SEPARADOR DECIMAL, SEPARADOR DE MILLES y USAR SEPARADOR DE MILLES.
ANEXAR WWW¶Predeterminado: False
Whether to agregar el subdominio «www.» a las URLs que no lo tienen. Esto se utiliza solo si está instalado el middleware CommonMiddleware (consulte Middleware). Consulte también la configuración APPEND_SLASH.
ROOT_URLCONF¶Predeterminado: No definido
Una cadena que representa la ruta de importación completa en Python a tu URLconf raíz, por ejemplo "mydjangoapps.urls". Puede sobrescribirse en una base por solicitud estableciendo el atributo urlconf en el objeto de solicitud entrante HttpRequest. Consulte Cómo procesa Django una solicitud para detalles.
SECRET_KEY¶Por defecto: '' (cadena vacía)
Una clave secreta para una instalación particular de Django. Se utiliza para proporcionar firmas criptográficas (consulte cryptographic signing), y debe establecerse en un valor único e impredecible.
django-admin startproject agrega automáticamente una clave secreta generada al azar a cada nuevo proyecto.
No se deben suponer usos del key que asuman que es texto o bytes. Cada uso debe pasar por force_str() o force_bytes() para convertirlo al tipo deseado.
Django rechazará iniciar si no se ha establecido la configuración SECRET_KEY.
Advertencia
Mantén este valor secreto.
Ejecutar Django con una clave secreta conocida desactiva muchas de las protecciones de seguridad de Django, y puede provocar vulnerabilidades de escalada de privilegios y ejecución de código remoto.
La traducción de los textos es la siguiente:
Todos sesiones si estás utilizando cualquier otro backend de sesión que no sea django.contrib.sessions.backends.cache, o si estás utilizando el get_session_auth_hash() por defecto.
Todas mensajes si estás utilizando CookieStorage o FallbackStorage.
Todos los tokens de PasswordResetView.
Cualquier uso de la firma criptográfica <topics/signing>, a menos que se proporcione una clave diferente.
Cuando ya no se establece la clave secreta como SECRET_KEY o se contiene dentro de SECRET_KEY_FALLBACKS, todas las opciones anteriores serán invalidadas. Al rotar tu clave secreta, debes mover la antigua a SECRET_KEY_FALLBACKS temporalmente. Las claves secretas no se utilizan para las contraseñas de los usuarios y la rotación de claves no afectará a ellas.
Nota
El archivo settings.py creado por defecto mediante django-admin startproject crea una clave secreta única SECRET_KEY con fines de conveniencia.
SECRET_KEY_FALLBACKS¶Lista por defecto: []
Una lista de claves secretas de fallback para una instalación particular de Django. Estas se utilizan para permitir la rotación de la clave secreta SECRET_KEY.
Para rotar tus claves secretas, establece una nueva SECRET_KEY y mueve el valor anterior al principio de SECRET_KEY_FALLBACKS. Luego elimina los valores antiguos del final de SECRET_KEY_FALLBACKS cuando estés listo para expirar las sesiones, tokens de restablecimiento de contraseña, etc., que utilicen esos valores.
Nota
Las operaciones de firma son computacionalmente costosas. Tener múltiples valores de clave antigua en SECRET_KEY_FALLBACKS agrega un overhead adicional a todas las comprobaciones que no coincidan con una clave anterior.
Por tanto, los valores de fallback deben eliminarse después de un período apropiado, lo que permite la rotación de claves.
Los usos de los valores de la clave secreta no deberían suponer que son texto o bytes. Cada uso debe pasar por force_str() o force_bytes() para convertirlo al tipo deseado.
SECURE_CONTENT_TYPE_NOSNIFF¶Predeterminado: True
Si True, el middleware de seguridad SecurityMiddleware establece la cabecera X-Content-Type-Options: nosniff en todas las respuestas que no ya la tienen.
SECURE_CROSS_ORIGIN_OPENER_POLICY¶Predeterminado: 'same-origin'
A menos que se establezca en None, el middleware de seguridad SecurityMiddleware establece la cabecera Política del Opener de Origen Cruzado en todas las respuestas que no ya la tienen con el valor proporcionado.
SECURE_HSTS_INCLUDE_SUBDOMAINS¶Predeterminado: False
Si True, el SecurityMiddleware agrega la directiva includeSubDomains al encabezado de seguridad del transporte HTTP (http-strict-transport-security). No tiene efecto a menos que se establezca SECURE_HSTS_SECONDS en un valor distinto de cero.
Advertencia
Establecer esta opción incorrectamente puede romper irreversiblemente tu sitio para el valor de SECURE_HSTS_SECONDS. Lee la documentación del encabezado de seguridad del transporte HTTP (http-strict-transport-security) primero.
SECURE_HSTS_PRELOAD¶Predeterminado: False
Si True, el SecurityMiddleware agrega la directiva preload al encabezado de seguridad del transporte HTTP (http-strict-transport-security). No tiene efecto a menos que se establezca SECURE_HSTS_SECONDS en un valor distinto de cero.
SECURE_HSTS_SECONDS¶Predeterminado: 0
Si se establece en un valor entero no cero, el SecurityMiddleware establece el encabezado de seguridad del transporte HTTP (http-strict-transport-security) en todas las respuestas que ya no lo tienen.
Advertencia
Establecer esta opción incorrectamente puede romper irreversiblemente tu sitio durante algún tiempo. Lee la documentación del encabezado de seguridad del transporte HTTP (http-strict-transport-security) primero.
SECURE_PROXY_SSL_HEADER¶Predeterminado: None
Un tupla que representa una combinación de encabezado y valor HTTP que indica que la solicitud es segura. Esto controla el comportamiento del método is_secure() del objeto de solicitud.
Por defecto, is_secure() determina si una solicitud es segura confirmando que una URL solicitada utiliza https://. Este método es importante para la protección CSRF de Django y puede ser utilizado por tu propio código o aplicaciones de terceros.
Si tu aplicación Django está detrás de un proxy, aunque, el proxy puede «engullir» si la solicitud original utiliza HTTPS o no. Si hay una conexión no HTTPS entre el proxy y Django entonces is_secure() siempre devolvería False – incluso para solicitudes que se realizaron mediante HTTPS por parte del usuario final. Por el contrario, si hay una conexión HTTPS entre el proxy y Django entonces is_secure() siempre devolvería True – incluso para solicitudes que originalmente se realizaron a través de HTTP.
En esta situación, configura tu proxy para establecer un encabezado HTTP personalizado que le diga a Django si la solicitud llegó mediante HTTPS, y establece SECURE_PROXY_SSL_HEADER para que Django sepa qué encabezado buscar.
Establece una tupla con dos elementos – el nombre del encabezado que busca y el valor requerido. Por ejemplo:
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
Esto le dice a Django que confíe en el encabezado X-Forwarded-Proto que proviene de nuestro proxy y que la solicitud está garantizada como segura (es decir, originalmente llegó mediante HTTPS) cuando:
el valor del encabezado es 'https', o
su primer valor inicial, izquierdo, es 'https' en el caso de una lista separada por comas de protocolos (por ejemplo 'https,http,http').
Debes solo establecer esta configuración si controlas tu proxy o tienes alguna otra garantía de que lo configura/stripe adecuadamente.
Ten en cuenta que el encabezado necesita estar en el formato utilizado por request.META – todo en mayúsculas y probablemente comenzando con HTTP_. (Recuerda, Django agrega automáticamente 'HTTP_' al principio de los nombres de encabezados x antes de hacer disponible el encabezado en request.META).
Advertencia
Modificando esta configuración puede comprometer la seguridad de tu sitio. Asegúrate de que comprendas completamente tu configuración antes de cambiarla.
Asegúrate de que sean verdaderos todos los siguientes (asumiendo los valores del ejemplo anterior):
Tu aplicación Django está detrás de un proxy.
Tu proxy elimina el encabezado X-Forwarded-Proto de todas las solicitudes entrantes, incluso cuando contiene una lista separada por comas de protocolos. En otras palabras, si los usuarios finales incluyen ese encabezado en sus solicitudes, el proxy lo descartará.
Tu proxy establece el encabezado X-Forwarded-Proto y lo envía a Django, pero solo para las solicitudes que originalmente llegan vía HTTPS.
Si ninguna de esas condiciones es cierta, debes mantener esta configuración en None y encontrar otra forma de determinar HTTPS, quizás mediante middleware personalizado.
SECURE_REDIRECT_EXEMPT¶Default: [] (Lista vacía)
Si una ruta URL coincide con un patrón regular en esta lista, la solicitud no se redirigirá a HTTPS. El SecurityMiddleware elimina las barras diagonales del principio de las rutas URL, por lo que los patrones no deben incluirlos, e.g. SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]. Si SECURE_SSL_REDIRECT es False, esta configuración no tiene efecto.
SECURE_REFERRER_POLICY¶Predeterminado: 'same-origin'
Si está configurado, el SecurityMiddleware establece el encabezado de política de referente en todas las respuestas que no ya lo tienen a la valor proporcionada.
SECURE_SSL_HOST¶Predeterminado: None
Si una cadena (e.g. secure.example.com), todos los redireccionamientos SSL se dirigirán a este host en lugar del originalmente solicitado (e.g. www.example.com). Si SECURE_SSL_REDIRECT es False, esta configuración no tiene efecto.
SECURE_SSL_REDIRECT¶Predeterminado: False
Si True, el middleware de seguridad SecurityMiddleware redirige todas las solicitudes no HTTPS a HTTPS (excepto aquellas URLs que coincidan con una expresión regular lista en SECURE_REDIRECT_EXEMPT).
Nota
Si poner esto a True provoca redirecciones infinitas, probablemente significa que tu sitio está corriendo detrás de un proxy y no puede determinar qué solicitudes son seguras y cuáles no. Es probable que tu proxy esté configurado para establecer una cabecera para indicar solicitudes seguras; puedes corregir el problema encontrando la cabecera correspondiente y configurando el SECURE_PROXY_SSL_HEADER según corresponda.
SERIALIZATION_MODULES¶Predeterminado: No definido
Un diccionario de módulos que contienen definiciones de serializadores (proporcionados como cadenas), identificados por una cadena para ese tipo de serialización. Por ejemplo, para definir un serializador YAML, utiliza:
SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}
SERVER_EMAIL¶Predeterminado: 'root@localhost'
La dirección de correo electrónico desde la que se envían los mensajes de error, como aquellos enviados a ADMINS y MANAGERS. Esta dirección se utiliza en el encabezado From: y puede tener cualquier formato válido en el protocolo de envío de correos elegido.
¿Por qué mis correos electrónicos están siendo enviados desde una dirección diferente?
Esta dirección solo se utiliza para mensajes de error. No es la dirección que los mensajes de correo electrónico regulares enviados con send_mail() provienen; para eso, consulta DEFAULT_FROM_EMAIL.
FECHA_CORTA_FORMATO¶Predeterminado: 'd/m/A'' (por ejemplo, 31/12/2003)
Una formación disponible que se puede utilizar para mostrar campos de fecha en plantillas. Ten en cuenta que la correspondiente formato dictaminado por el idioma tiene una mayor precedencia y se aplicará en su lugar. Consulte cadenas de formato de fecha permitidas.
Consulte también FORMATO_FECHA y FECHA_CORTA_FORMATO_HORA.
FECHA_CORTA_FORMATO_HORA¶Predeterminado: 'd/m/A H' (por ejemplo, 31/12/2003 16 h)
Una formación disponible que se puede utilizar para mostrar campos de fecha y hora en plantillas. Ten en cuenta que la correspondiente formato dictaminado por el idioma tiene una mayor precedencia y se aplicará en su lugar. Consulte cadenas de formato de fecha permitidas.
Consulte también FORMATO_FECHA y FECHA_CORTA_FORMATO.
BACKEND_DE_FIRMAS¶Predeterminado: 'django.core.signing.TimestampSigner'
El backend utilizado para firmar cookies y otros datos.
Consulte también la documentación La firma criptográfica.
SILENCED_SYSTEM_CHECKS¶Default: [] (Lista vacía)
Una lista de identificadores de mensajes generados por el marco de trabajo de comprobaciones del sistema (es decir, ["models.W001"]) que deseas ignorar permanentemente y silenciar. Las comprobaciones silenciadas no se mostrarán en la consola.
Consulte también la documentación Marco del sistema de comprobaciones.
STORAGES¶Predeterminado:
{
"default": {
"BACKEND": "django.core.files.storage.FileSystemStorage",
},
"staticfiles": {
"BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage",
},
}
Un diccionario que contiene las configuraciones para todos los almacenes a utilizar con Django. Es un diccionario anidado cuyos contenidos mapean un alias de almacenamiento a un diccionario que contiene las opciones para un almacenamiento individual.
Los almacenes pueden tener cualquier alias que elijas. Sin embargo, hay dos aliases con significado especial:
default para gestionar archivos. ``”:class:`django.core.files.storage.FileSystemStorage``”` es el motor de almacenamiento por defecto.
staticfiles para gestionar archivos estáticos. ``”:class:`django.contrib.staticfiles.storage.StaticFilesStorage``”` es el motor de almacenamiento por defecto.
El siguiente es un ejemplo de fragmento settings.py que define una almacenamiento personalizado llamado example:
STORAGES = {
# ...
"example": {
"BACKEND": "django.core.files.storage.FileSystemStorage",
"OPTIONS": {
"location": "/example",
"base_url": "/example/",
},
},
}
Se pasan opciones al BACKEND en la inicialización en **kwargs.
Una instancia lista para usar del almacenamientos backends se puede obtener desde django.core.files.storage.storages. Utiliza una clave correspondiente a la definición de backend en STORAGES.
¿Mi valor está combinado con el valor por defecto?
Definir esta configuración sobreescribe el valor por defecto y no se combina con él.
TEMPLATES¶Default: [] (Lista vacía)
Una lista conteniendo las configuraciones para todos los motores de plantillas a utilizar con Django. Cada elemento de la lista es un diccionario conteniendo las opciones para un motor individual.
Aquí tienes una configuración que le dice al motor de plantillas de Django cargar plantillas desde el subdirectorio templates dentro de cada aplicación instalada:
TEMPLATES = [
{
"BACKEND": "django.template.backends.django.DjangoTemplates",
"APP_DIRS": True,
},
]
Las siguientes opciones están disponibles para todos los backends.
BACKEND¶Predeterminado: No definido
El backend de plantilla a utilizar. Los backends de plantillas integrados son:
'django.template.backends.django.DjangoTemplates'
'django.template.backends.jinja2.Jinja2'
Puedes utilizar un motor de plantillas que no viene incluido con Django estableciendo BACKEND a una ruta completa (i.e. 'mypackage.whatever.Backend').
NAME¶Predeterminado: consulta a continuación
El alias para este motor de plantillas en particular. Es un identificador que permite seleccionar un motor para la renderización. Los aliases deben ser únicos entre todos los motores de plantillas configurados.
Por defecto se ajusta al nombre del módulo que define la clase del motor, es decir, el siguiente a último trozo de BACKEND, cuando no se proporciona. Por ejemplo si el backend es 'mypackage.whatever.Backend' entonces su nombre por defecto es 'whatever'.
DIRS¶Default: [] (Lista vacía)
Los directorios donde el motor debe buscar archivos de origen de plantillas, en orden de búsqueda.
APP_DIRS¶Predeterminado: False
Si el motor debe buscar archivos de origen de plantillas dentro de las aplicaciones instaladas.
Nota
El archivo de configuración por defecto settings.py creado por django-admin startproject establece 'APP_DIRS': True.
OPCIONES¶Por defecto: {} (Diccionario vacío)
Parámetros adicionales para pasar al backend de plantillas. Los parámetros disponibles varían según el backend de plantillas. Consulte las opciones de los backends integrados en DjangoTemplates y Jinja2.
TEST_RUNNER¶Por defecto: 'django.test.runner.DiscoverRunner'
El nombre de la clase para utilizar al iniciar el conjunto de pruebas. Consulte otros-frameworks-de-pruebas.
TEST_NON_SERIALIZED_APPS¶Default: [] (Lista vacía)
Para restaurar el estado del servidor de bases de datos entre las pruebas para TransactionTestCases y backends de base de datos sin transacciones, Django serializará los contenidos de todas las aplicaciones al iniciar la ejecución de las pruebas para que luego pueda cargar desde esa copia antes de ejecutar las pruebas que lo necesiten.
Esto ralentiza el tiempo de inicio del ejecutor de pruebas; si tienes aplicaciones que sabes que no necesitan esta característica, puedes agregar sus nombres completos aquí (por ejemplo 'django.contrib.contenttypes') para excluirlas de este proceso de serialización.
THOUSAND_SEPARATOR¶Default: “,” (Coma)
El separador de miles utilizado por defecto al formatear números. Esta configuración se utiliza solo cuando USE_THOUSAND_SEPARATOR es True y NUMBER_GROUPING es mayor que 0.
Ten en cuenta que el formato determinado por la localización tiene mayor precedencia y se aplicará en su lugar.
También consulta NUMBER_GROUPING, DECIMAL_SEPARATOR y USE_THOUSAND_SEPARATOR.
Por defecto: 'P' (por ejemplo, 4 p.m.)
La formación por defecto para mostrar campos de tiempo en cualquier parte del sistema. Tenga en cuenta que la forma determinada por el idioma tiene mayor precedencia y se aplicará en su lugar. Consulte cadenas de formato de fecha permitidas.
Ver también FORMATO_FECHA y FORMATO_HORA_FECHA.
Predeterminado:
[
"%H:%M:%S", # '14:30:59'
"%H:%M:%S.%f", # '14:30:59.000200'
"%H:%M", # '14:30'
]
Una lista de formatos que se aceptarán cuando se ingrese datos en un campo de fecha. Se intentará utilizar los formatos en orden, utilizando el primero válido. Ten en cuenta que estas cadenas de formato utilizan la sintaxis del módulo datetime de Python, no las cadenas de formato del filtro de plantilla date.
El formato determinado por la configuración de localización tiene mayor precedencia y se aplicará en su lugar.
Ver también FORMATOS DE ENTRADA DE FECHA y FORMATOS DE ENTRADA DE HORA Y FECHA.
ZONA HORARIA¶Por defecto: 'America/Chicago'
Una cadena representando la zona horaria para esta instalación. Consulta la **lista de zonas horarias**_.
Nota
Dado que Django se lanzó por primera vez con la configuración TIME_ZONE establecida en 'America/Chicago', la configuración global (utilizada si no se define nada en el archivo settings.py de tu proyecto) sigue siendo 'America/Chicago' para compatibilidad hacia atrás. Los nuevos plantillas de proyectos por defecto están configurados en 'UTC'.
Ten en cuenta que esto no es necesariamente la zona horaria del servidor. Por ejemplo, un servidor puede servir varios sitios web impulsados por Django, cada uno con una configuración de zona horaria separada.
Cuando la configuración USE_TZ es False, esta es la zona horaria en la que Django almacenará todos los tiempos. Cuando la configuración USE_TZ es True, esta es la zona horaria por defecto que Django utilizará para mostrar los tiempos en las plantillas y para interpretar los tiempos introducidos en formularios.
En entornos de Unix (donde se implementa la función time.tzset), Django establece la variable os.environ['TZ'] en la zona horaria que especifiques en el parámetro TIME_ZONE. De este modo, todas tus vistas y modelos operarán automáticamente en esta zona horaria. Sin embargo, Django no establecerá la variable de entorno TZ si estás utilizando la opción de configuración manual descrita en configurando settings sin módulo django.settings. Si Django no establece la variable de entorno TZ, es responsabilidad tuya asegurar que tus procesos se ejecutan en el entorno correcto.
Nota
Django no puede utilizar de manera fiable las zonas horarias alternativas en un entorno de Windows. Si estás ejecutando Django en Windows, TIME_ZONE debe estar configurado para coincidir con la zona horaria del sistema.
USE_I18N`¶Predeterminado: True
Una variable booleana que especifica si el sistema de traducción de Django debe estar habilitado. Esto proporciona una forma de deshabilitarlo, para mejorar el rendimiento. Si se establece en False, Django realizará algunas optimizaciones para no cargar la maquinaria de traducción.
Ver también CODIGO_DE_IDIOMA y USO_DE_ZONA_HORARIA.
Nota
El default archivo settings.py creado por django-admin startproject incluye USE_I18N = True para conveniencia.
USE_THOUSAND_SEPARATOR¶Predeterminado: False
Una booleana que especifica si se deben mostrar números utilizando un separador de miles. Cuando se establece en True, Django formateará los números utilizando las configuraciones NUMBER_GROUPING y THOUSAND_SEPARATOR. Las dos últimas configuraciones también pueden ser dictadas por la localización, que tiene prioridad.
También ver: DECIMAL_SEPARATOR, NUMBER_GROUPING y THOUSAND_SEPARATOR.
USE_TZ¶Predeterminado: True
Una booleana que especifica si los datetimes serán conscientes de zona horaria por defecto o no. Si se establece en True, Django utilizará datetimes conscientes de zona horaria internamente.
Cuando USE_TZ es False, Django utilizará datetimes ingenuas en tiempo local, excepto cuando se esté parseando cadenas formateadas con ISO 8601, donde la información de zona horaria siempre se retendrá si está presente.
USE_X_FORWARDED_HOST¶Predeterminado: False
Una booleana que especifica si se debe utilizar el encabezado X-Forwarded-Host en lugar del encabezado Host. Esto solo debería estar habilitado si se está utilizando un proxy que establezca este encabezado.
Este setting tiene prioridad sobre USE_X_FORWARDED_PORT. Según la especificación de RFC 7239#section-5.3, el encabezado X-Forwarded-Host puede incluir el número de puerto, en cuyo caso no debes utilizar USE_X_FORWARDED_PORT.
Predeterminado: False
Un booleano que especifica si se debe utilizar el encabezado X-Forwarded-Port en lugar de la variable SERVER_PORT META. Esto solo debería estar habilitado si se utiliza un proxy que establezca este encabezado.
USE_X_FORWARDED_HOST tiene prioridad sobre esta configuración.
Predeterminado: None
La ruta completa de Python del objeto de aplicación WSGI que utilizarán los servidores integrados de Django (por ejemplo, runserver). El comando de administración django-admin startproject <startproject> creará un archivo estándar wsgi.py con una función llamable application en él, y apuntará esta configuración a esa función.
Si no se establece, se utilizará el valor de retorno de django.core.wsgi.get_wsgi_application(). En este caso, el comportamiento de runserver será idéntico a las versiones anteriores de Django.
Predeterminado: 'F Y'
La formación predeterminada que se utiliza para los campos de fecha en las páginas de cambio del administrador de Django – y, posiblemente, por otras partes del sistema – en casos en los que solo se muestran el año y el mes.
Los textos traducidos son:
Ten en cuenta que el formato determinado por la correspondiente locale tiene mayor precedencia y se aplicará en su lugar.
Ver cadenas de formato de fecha permitidas. Ver también FORMATO DE FECHA, FORMATO DE HORA Y FECHA, FORMATO DE HORA y FORMATO DE DÍA Y MES.
X_FRAME_OPTIONS¶Valor por defecto: 'DENY'
El valor por defecto para la cabecera X-Frame-Options utilizada por el middleware XFrameOptionsMiddleware. Consulte la documentación de protección contra clickjacking <clickjacking/>.
Configuraciones para django.contrib.auth.
AUTHENTICATION_BACKENDS¶Valor por defecto: ['django.contrib.auth.backends.ModelBackend']
Una lista de clases de backends de autenticación (como cadenas) a utilizar cuando se intenta autenticar a un usuario. Consulte la documentación sobre backends de autenticación <authentication-backends> para obtener más detalles.
AUTH_USER_MODEL¶Predeterminado: 'auth.User'
El modelo a utilizar para representar un Usuario. Consulte la sección Sustituyendo un modelo User personalizado.
Advertencia
No puedes cambiar el ajuste de AUTH_USER_MODEL durante la vida útil de un proyecto (es decir, una vez que hayas creado y migrado modelos que dependen de él) sin un esfuerzo serio. Se pretende configurarlo al inicio del proyecto, y el modelo a el que se refiere debe estar disponible en la primera migración de la aplicación a la que pertenece. Consulte la sección Sustituyendo un modelo User personalizado para obtener más detalles.
LOGIN_REDIRECT_URL¶Predeterminado: '/accounts/profile/'
La URL o el patrón de URL nombrada <naming-url-patterns> donde las solicitudes se redirigen después del inicio de sesión cuando la vista LoginView no recibe un parámetro GET next.
LOGIN_URL¶Predeterminado: '/accounts/login/'
La URL o el patrón de URL nombrada <naming-url-patterns> donde las solicitudes se redirigen para iniciar sesión cuando se utiliza el decorador login_required(), la clase LoginRequiredMixin, la clase AccessMixin o cuando está instalado el middleware LoginRequiredMiddleware.
Predeterminado: None
La URL o el patrón de URL nombrado <naming-url-patterns> donde se redirigen las solicitudes después del cierre de sesión si la vista de cierre de sesión ~django.contrib.auth.views.LogoutView no tiene una atributo next_page.
Si es None, no se realizará ninguna redirección y se renderizará la vista de cierre de sesión.
Predeterminado: 259200 (3 días, en segundos)
El número de segundos que un enlace de restablecimiento de contraseña es válido.
Utilizado por la vista ~django.contrib.auth.views.PasswordResetConfirmView.
Nota
Reducir el valor de este tiempo de espera no hace ninguna diferencia a la capacidad de un atacante para forzar una token de restablecimiento de contraseña. Los tokens están diseñados para ser seguros contra fuerza bruta sin ningún tiempo de espera.
Este tiempo de espera existe para protegerse contra algunos escenarios de ataques poco probables, como alguien accediendo a archivos de correo electrónico que pueden contener antiguos tokens de restablecimiento de contraseña no utilizados.
See almacenamiento_de_contraseña_autenticación.
Predeterminado:
[
"django.contrib.auth.hashers.PBKDF2PasswordHasher",
"django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher",
"django.contrib.auth.hashers.Argon2PasswordHasher",
"django.contrib.auth.hashers.BCryptSHA256PasswordHasher",
"django.contrib.auth.hashers.ScryptPasswordHasher",
]
VALIDADORES_DE_CONTRASEÑA_AUTENTICACIÓN¶Default: [] (Lista vacía)
La lista de validadores que se utilizan para comprobar la fuerza de las contraseñas de los usuarios. Consulta validación de contraseña para obtener más detalles. Por defecto, no se realiza ninguna validación y todas las contraseñas son aceptadas.
Configuraciones para django.contrib.messages.
NIVEL_DE_MENSAJE¶Predeterminado: mensajes.INFO
Establece el nivel mínimo de mensaje que se grabará por el marco de mensajes. Consulta niveles de mensaje para obtener más detalles.
Evitando importaciones circulares
Si sobreescribes NIVEL_DE_MENSAJE en tu archivo de configuración y dependes de alguna de las constantes incorporadas, debes importar el módulo de constantes directamente para evitar el potencial de importaciones circulares, por ejemplo:
from django.contrib.messages import constants as message_constants
MESSAGE_LEVEL = message_constants.DEBUG
Si lo deseas, puedes especificar los valores numéricos de las constantes directamente según los valores en la tabla anterior: <message-level-constants>.
MESSAGE_STORAGE¶Predeterminado: 'django.contrib.messages.storage.fallback.FallbackStorage'
Controla dónde Django almacena los datos de mensajes. Los valores válidos son:
'django.contrib.messages.storage.fallback.FallbackStorage'
'django.contrib.messages.storage.session.SessionStorage'
'django.contrib.messages.storage.cookie.CookieStorage'
Consulte los backends de almacenamiento de mensajes <message-storage-backends> para obtener más detalles.
Los backends que utilizan cookies – CookieStorage y FallbackStorage – utilizan el valor de SESSION_COOKIE_DOMAIN, SESSION_COOKIE_SECURE y SESSION_COOKIE_HTTPONLY al establecer sus cookies.
Configuración para django.contrib.sessions.
Default: 'default'
Si estás utilizando cache-based session storage, esta selecciona la caché a utilizar.
SESSION_ENGINE¶Predeterminado: 'django.contrib.sessions.backends.db'
Controla dónde Django almacena los datos de sesión. Los motores incluidos son:
``”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'
Vea configurando-sesiones para obtener más detalles.
SESSION_EXPIRE_AT_BROWSER_CLOSE¶Predeterminado: False
¿Expirar la sesión cuando el usuario cierra su navegador? Vea sesiones-de-navegador-vs-persistentes.
SESSION_FILE_PATH¶Predeterminado: None
Si está utilizando almacenamiento de sesiones basado en archivos, esta establece el directorio en el que Django almacenará los datos de sesión. Cuando se utiliza el valor por defecto (None), Django utilizará el directorio temporal estándar del sistema.
SESSION_SAVE_EVERY_REQUEST¶Predeterminado: False
¿Guardar los datos de sesión en cada solicitud? Si este valor es False (por defecto), entonces los datos de sesión solo se guardarán si han sido modificados – es decir, si cualquier de sus valores del diccionario ha sido asignado o eliminado. No se crearán sesiones vacías, ni siquiera si esta configuración está activada.
SESSION_SERIALIZER¶Por defecto: 'django.contrib.sessions.serializers.JSONSerializer'
Ruta de importación completa de una clase de serializador para usar al serializar los datos de sesión. Se incluye el siguiente serializador:
'django.contrib.sessions.serializers.JSONSerializer'
Consulte Session serialización para obtener más detalles.
Configuración para django.contrib.sites.
SITE_ID¶Predeterminado: No definido
Los textos traducidos son:
Configuración para django.contrib.staticfiles.
STATIC_ROOT¶Predeterminado: None
La ruta absoluta al directorio donde collectstatic recopilará archivos estáticos para la depuración.
Ejemplo: "/var/www/example.com/static/"
Si la aplicación contributiva de archivos estáticos (staticfiles) está habilitada (como en el plantilla de proyecto por defecto), el comando administrativo collectstatic recopilará los archivos estáticos en este directorio. Consulte la guía sobre cómo gestionar los archivos estáticos (managing static files) para obtener más detalles sobre su uso.
Advertencia
Este debe ser un directorio de destino vacío inicialmente para recopilar tus archivos estáticos desde sus ubicaciones permanentes a uno solo para facilitar la depuración; no es un lugar donde almacenar los archivos estáticos permanentemente. Debes hacerlo en directorios que se encuentren por staticfiles’s finders, que, por defecto, son subdirectorios de aplicaciones 'static/' y cualquier directorio que incluyas en STATICFILES_DIRS.
STATIC_URL¶Predeterminado: None
URL a utilizar al referirse a archivos estáticos ubicados en STATIC_ROOT.
"static/" o "https://static.example.com/"
Si no es None, se utilizará como ruta base para las definiciones de activos (la clase Media) y la aplicación de archivos estáticos <ref/contrib/staticfiles>.
Debe terminar en una barra si se establece en un valor no vacío.
Es posible que debas configurar estos archivos para servirlos en desarrollo y, sin duda, lo necesitarás en producción.
Nota
Si la variable de entorno STATIC_URL es una ruta relativa, entonces se prefijará con el valor proporcionado por el servidor de SCRIPT_NAME (o / si no está configurado). Esto facilita servir una aplicación Django en un subruta sin agregar una configuración adicional a las configuraciones.
Default: [] (Lista vacía)
Esta variable define los ubicaciones adicionales que la aplicación de archivos estáticos recorrerá si el finder FileSystemFinder está habilitado, por ejemplo, si utilizas el comando de administración collectstatic o findstatic, o si utilizas la vista de servicio de archivos estáticos.
Debería establecerse en una lista de cadenas que contengan rutas completas a tus directorios de archivos adicionales (s), por ejemplo:
STATICFILES_DIRS = [
"/home/special.polls.com/polls/static",
"/home/polls.com/polls/static",
"/opt/webfiles/common",
]
Ten en cuenta que estas rutas deben utilizar diagonales Unix, incluso en Windows (por ejemplo "C:/Users/user/mysite/extra_static_content").
En caso de que desees hacer referencia a archivos en una de las ubicaciones con un espacio de nombres adicional, puedes opcionalmente proporcionar un prefijo como tuplas de (prefijo, ruta) , por ejemplo:
STATICFILES_DIRS = [
# ...
("downloads", "/opt/webfiles/stats"),
]
Por ejemplo, suponiendo que tengas establecido STATIC_URL en 'static/', el comando de administración collectstatic recopilaría los archivos «stats» en una subcarpeta 'downloads' de STATIC_ROOT.
Esta permitiría que se refiera al archivo local '/opt/webfiles/stats/polls_20101022.tar.gz' con '/static/downloads/polls_20101022.tar.gz' en tus plantillas, por ejemplo:
<a href="{% static 'downloads/polls_20101022.tar.gz' %}">
Predeterminado:
[
"django.contrib.staticfiles.finders.FileSystemFinder",
"django.contrib.staticfiles.finders.AppDirectoriesFinder",
]
La lista de backends de búsqueda que saben encontrar archivos estáticos en diversas ubicaciones.
La configuración predeterminada encontrará archivos almacenados en la configuración STATICFILES_DIRS (utilizando django.contrib.staticfiles.finders.FileSystemFinder) y en una subcarpeta static de cada aplicación (utilizando django.contrib.staticfiles.finders.AppDirectoriesFinder). Si están presentes múltiples archivos con el mismo nombre, se utilizará el primer archivo que se encuentre.
Un finder está deshabilitado por defecto: django.contrib.staticfiles.finders.DefaultStorageFinder. Si se agrega a tu configuración STATICFILES_FINDERS, buscará archivos estáticos en el almacenamiento de archivos predeterminado definido por la clave default en la configuración STORAGES.
Nota
Cuando se utiliza el buscador AppDirectoriesFinder, asegúrate de que tus aplicaciones puedan ser encontradas por staticfiles agregando la aplicación a la configuración INSTALLED_APPS de tu sitio.
Los buscadores de archivos estáticos se consideran actualmente una interfaz privada, y esta interfaz no está documentada por lo tanto.
DEBUG
DEBUG_PROPAGATE_EXCEPTIONS
ADMINS
CHARACTER DE PRESENCIA POR DEFECTO
DEFAULT_FROM_EMAIL
EMAIL_BACKEND
EMAIL_FILE_PATH
EMAIL_HOST
EMAIL_HOST_PASSWORD
USUARIO_DE_CORREO_EMAIL
PUERTO_DE_CORREO_EMAIL
CERTIFICADO_SSL_DE_CORREO_EMAIL
ARCHIVO_LLAVE_SSL_DE_CORREO_EMAIL
PREFIXIO_DE_ASUNTO_DE_CORREO_EMAIL
TIEMPO_DE_CONEXION_DE_CORREO_EMAIL
USAR_HORA_LOCAL_EN_CORREO_EMAIL
USAR_SSL_EN_CORREO_EMAIL
USAR_TLS_EN_CORREO_EMAIL
ADMINISTRADORES
CORREO_DEL_SERVIDOR
REPORTADOR_DE_EXCEPCIONES_POR_DEFECTO
FILTRO_DE_REPORTADO_DE_EXCEPCIONES_POR_DEFECTO
URLs que se ignoran en caso de 404
ADMINISTRADORES
SISTEMA_DE_VERIFICACIONES_SILENCIADAS
MANEJADORES_DE_CARGA_DE_ARCHIVOS
TAMAÑO_MAXIMO_DE_MEMORIA_PARA_SUBIR_ARCHIVOS
PERMISOS_DE_CARGA_DE_ARCHIVOS
DIRECTORIO_TEMPORAL_DE_SUBIDA_DE_ARCHIVOS
RAÍZ_MEDIOS
URL_MEDIOS
RENDERIZADOR_FORMULARIOS
FORM_URLFIELD_ASUME_HTTPS
i18n/l10n)¶i18n)¶PRIMER_DÍA_DE_LA_SEMANA
CAMINO_MÓDULO_FORMATO
EDAD_COOKIE_IDIOMA
DOMINIO_COOKIE_IDIOMA
COOKIE_DE LENGUAJE_HTTPONLY
NOMBRE DEL COOKIE DE LENGUAJE
RUTA DEL COOKIE DE LENGUAJE
COOKIE_DE LENGUAJE_SAMESITE
COOKIE_DE LENGUAJE_SEGURA
IDIOMAS
IDIOMAS_BIDI
RUTAS DE LOCALE
ZONA HORARIA
USO_DE_I18N
USE_TZ
l10n)¶FORMATO_DE_FECHA
FORMATOS_DE_INGRESO_DE_FECHA
DATETIME_FORMAT
FORMATOS_DE_INGRESO_DE_HORA
SEPARADOR_DECIMAL
CÓDIGO DE LENGUAJE
FORMATO_DE_MES_Y_DÍA
NÚMERO_DE_GRUPADO
FORMATO DE FECHA CORTA
FORMATO DE FECHA Y HORA CORTA
SEPARADOR DE MILLE
FORMATO DE HORA
FORMATOS DE ENTRADA DE HORA
USAR SEPARADOR DE MILLEDADES
FORMATO DE AÑO Y MES
TAMAÑO MÁXIMO DE MEMORIA PARA SUBIR DATOS
NÚMERO MÁXIMO DE CAMPOS QUE PUEDE SUBIRSE EN UN FORMULARIO
NÚMERO MÁXIMO DE ARCHIVOS QUE PUEDE SUBIRSE EN UN FORMULARIO
CHARACTER DE PRESENCIA POR DEFECTO
AGENTES DE USUARIO PROHIBIDOS
FORZAR_NOMBRE_DE_SCRIPT
DOMINIOS_IP_INTERNOS
Seguridad
POLÍTICA DE ORIGEN CROS SEGURA
INCLUIR SUBDOMINIOS EN LA POLÍTICA HSTS SEGURA
CARGAR ANTES PRELOAD HSTS SEGURA
TIEMPO DE VIGENCIA DE LA POLÍTICA HSTS SEGURA
ENCABEZADO_PROXY_SSL_SEGURA
EXENTES DE REDIRECCIÓN SEGURA
POLÍTICA DEL REFERENTE SEGURA
DOMINIO SSL SEGURA
REDIRECCIONAR A HTTPS
BACKEND_FIRMA
USAR_X_FORWARDED_HOST
USAR_X_FORWARDED_PORT
APLICACIÓN_WSGI
REGISTRO_LOGUEO
CONFIGURACIÓN_REGISTRO
Protección contra ataques de Cross Site Request Forgery
CHARACTER DE PRESENCIA POR DEFECTO
Database: BASE DE DATOS DE PRUEBA
APLICACIONES NO SERIALIZADAS EN PRUEBA
EJECUTOR DE PRUEBAS
ANEXAR SLASH
PREPONDER WWWW
CONF DE RUTAS RAIZ
may 31, 2026