互联网是一个恶劣的环境。在部署你的 Django 项目之前，你应该将安全、性能和操作铭记于心，并花一些时间来检查你的配置。
Django 包含了许多 安全特性。一些是内置的并且总保持激活状态，其他的则是可选的因为它们不总是恰当的，或者因为它们不便于之后的开发。举个例子，强制的 HTTPS 并不一定适合所有网站，它对于本地开发就是不切实际的。
性能优化是另一项便利性权衡的主题。例如，缓存在生成环境很有用，但是对本地开发就作用不大。错误报告的需求也大不相同。
以下清单包括以下配置：
许多配置项是敏感的，需要被当做机密对待。如果要发布项目源码，常见操作是为开发开放合适的配置项，为生产环境配置私密设置模块。
manage.py check --deploy¶下面介绍的某些检查项会自动使用 check --deploy 选项。请确保根据选项文档中描述的生产设置文件运行它。
SECRET_KEY¶密码必须是一个较长的随机值，且被妥善保存。
确保生产环境使用的密码并未用于其它环境，且未被提交至版本控制系统。这将减少攻击者获取密码的概率。
逾期将安全密码硬编码在配置模块中，不然考虑从环境变量加载它:
import os
SECRET_KEY = os.environ['SECRET_KEY']
或者从一个文件:
with open('/etc/secret_key.txt') as f:
SECRET_KEY = f.read().strip()
DEBUG¶永远不要在生产环境打开 debug 开关。
开发时，你当然要配置 DEBUG = True，这将方便你在浏览器启用完全回溯功能。
不过，对于生产环境来说，这真是一个坏主意，因为这会泄露很多超出预期的信息：代码摘要，本地变量，配置项，使用的库，等等。
ALLOWED_HOSTS¶DEBUG = False 时，Django 在未正确配置 ALLOWED_HOSTS 时无法工作。
该配置避免你的站点遭受某些 CSRF 攻击。如果使用了通配符，你必须实现自定义的 Host HTTP 头，或者确保你不会很容易地遭受此种攻击。
你也需要配置挡在 Django 之前的 Web 服务器，让它验证主机。它应该忽略来自错误主机的请求，或返回静态错误页，而不是将请求重定向至 Django。这样做能避免 Django 日志中出现虚假错误（或在配置此种错误后，避免发送错误报告邮件）。例如，在 nginx 上，你可能配置了一个默认主机，为未识别的主机返回 "444 No Response"：
server {
listen 80 default_server;
return 444;
}
CACHES¶若使用了缓存，开发环境的连接参数和生产环境可能不同。Djano 默认为每个进程提供 本地内存缓存，这可能与期望不同。
缓存服务器一般采用弱验证。确保它们只接受来自你的应用服务器的连接。
DATABASES¶生产环境与开发环境的数据库连接参数可能是不同的。
数据库密码是机密的。你应该像保护 SECRET_KEY 那样保护它们。
为了最大限度的安全，确保数据库只为来自你应用的连接提供服务。
如果你还未为数据库设置备份，现在就做！
STATIC_ROOT 和 STATIC_URL¶静态文件由开发服务器自动托管。但在生产环境，你必须定义配置 STATIC_ROOT ， collectstatic 将会拷贝它们。
查看 管理静态文件（比如图片、JavaScript、CSS） 获得更多信息。
MEDIA_ROOT 和 MEDIA_URL¶媒体文件由用户上传。他们是不可信任的！确保 web 服务器从未尝试解析这些文件。例如，若用户上传了一个 .php 文件，web 服务器应该永远不要运行它。
现在是检查这些文件的备份策略的好时机。
允许用户登录的网站应该强制站点范围的 HTTPS，避免明文传输令牌。在 Django 中，令牌包括账号/密码，会话 cookie 和重置密码的令牌。（如果你用邮件发送重置密码的令牌，那就没什么办法能保护它们。）
仅保护用户账号或后台等敏感区域是不够的，因为 HTTP 和 HTTPS 使用相同的会话 cookie。Web 服务器必须将所有的 HTTP 重定向至 HTTPS，且只将 HTTPS 的请求转发给 Django。
若你已经配置了 HTTPS，启用下列配置。
CSRF_COOKIE_SECURE¶将此设置为 True，避免不甚用 HTTP 传输 CSRF cookie。
SESSION_COOKIE_SECURE¶将此设置未 True，避免不甚用 HTTP 传输会话 cookie。
配置 DEBUG = False 会禁用几个仅在开发时有用的功能。另外，你要调整下列配置。
12月 07, 2021