互联网是一个充满敌意的环境。在部署Django项目之前，您应该花一些时间检查您的设置，并考虑安全性、性能和操作。
Django包括很多 security features . 有些是内置的，并且始终启用。其他选项是可选的，因为它们并不总是合适的，或者因为它们不方便开发。例如，强制HTTPS可能不适用于所有网站，并且对于本地开发来说是不现实的。
性能优化是另一种方便的权衡。例如，缓存在生产中很有用，而在本地开发中则不那么有用。错误报告需求也大不相同。
以下检查表包括以下设置：
必须为Django适当设置，以提供预期的安全水平；
在每个环境中都是不同的；
启用可选的安全功能；
启用性能优化；
提供错误报告。
其中许多设置都是敏感的，应视为机密。如果要发布项目的源代码，通常的做法是发布适合开发的设置，并使用私有设置模块进行生产。
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()
如果轮换密钥，您可以使用 SECRET_KEY_FALLBACKS **
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
确保将旧的密钥从 SECRET_KEY_FALLBACKS 及时采取行动。
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¶如果您使用的是缓存，那么在开发和生产中连接参数可能会有所不同。Django默认为每个进程 local-memory caching 这可能是不可取的。
缓存服务器通常具有弱身份验证。确保它们只接受来自应用服务器的连接。
DATABASES¶数据库连接参数在开发和生产中可能有所不同。
数据库密码非常敏感。你应该像保护他们一样保护他们 SECRET_KEY .
为了获得最大的安全性，请确保数据库服务器只接受来自应用程序服务器的连接。
如果您尚未为数据库设置备份，请立即执行！
STATIC_ROOT and STATIC_URL¶静态文件由开发服务器自动提供服务。在生产中，必须定义 STATIC_ROOT 目录在哪里 collectstatic 将复制它们。
见 如何管理静态文件(如图像、JavaScript、css) 更多信息。
MEDIA_ROOT and MEDIA_URL¶媒体文件由用户上载。他们不可信！确保您的Web服务器从不尝试解释它们。例如，如果用户上载 .php 文件，Web服务器不应该执行它。
现在是检查这些文件的备份策略的好时机。
任何允许用户登录的网站都应该强制使用站点范围的HTTPS，以避免清晰地传输访问令牌。在Django中，访问令牌包括登录/密码、会话cookie和密码重置令牌。（如果您通过电子邮件发送密码重置令牌，则无法对其进行太多保护。）
保护敏感区域（如用户帐户或管理员）是不够的，因为HTTP和HTTPS使用相同的会话cookie。您的Web服务器必须将所有HTTP流量重定向到HTTPS，并且只将HTTPS请求传输到Django。
设置完https后，启用以下设置。
设置 DEBUG = False 禁用仅在开发中有用的几个功能。此外，您还可以调整以下设置。
考虑使用 cached sessions 以提高性能。
如果使用数据库支持的会话，则定期 clear old sessions 以避免存储不必要的数据。
CONN_MAX_AGE¶有可能 persistent database connections 在很大一部分请求处理时间内，当连接到数据库帐户时会导致很快的速度。
这对网络性能有限的虚拟主机有很大帮助。
TEMPLATES¶启用缓存模板加载器通常会显著提高性能，因为它避免了每次需要呈现每个模板时都对其进行编译。什么时候 DEBUG = False ，则会自动启用缓存模板加载器。看见 django.template.loaders.cached.Loader 以获取更多信息。
当您将代码推送到生产环境时，希望它是健壮的，但是您不能排除意外的错误。谢天谢地，Django可以捕获错误并相应地通知您。
LOGGING¶在将您的网站投入生产之前，请检查您的日志配置，并在收到一些流量后立即检查它是否按预期工作。
见 登录 有关日志记录的详细信息。
ADMINS and MANAGERS¶ADMINS 将通过电子邮件通知500个错误。
MANAGERS 将收到404个错误的通知。 IGNORABLE_404_URLS 有助于过滤虚假报告。
见 如何管理错误报告 有关通过电子邮件报告错误的详细信息。
电子邮件错误报告的扩展性不太好
考虑使用错误监视系统，例如 Sentry 在你的收件箱被报告淹没之前。哨兵也可以收集原木。
Django包括几个HTTP错误代码的默认视图和模板。您可能希望通过在根模板目录中创建以下模板来覆盖默认模板： 404.html ， 500.html ， 403.html ，以及 400.html 。这个 default error views 使用这些模板应该可以满足99%的Web应用程序的需求，但您可以 customize them 也是。
12月 18, 2023