部署清单
部署清单
互联网是一个敌对的环境。在部署Django项目之前,您应该花一些时间在考虑安全性,性能和操作的情况下检查设置。
Django包含许多安全功能。有些是内置的,并且始终启用。其他选项是可选的,因为它们并不总是合适的,或者因为它们不方便开发。例如,强制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()
DEBUG
您绝不能在生产中启用调试。
当然,您正在使用开发您的项目,因为这将启用方便的功能,例如浏览器中的完整追溯。DEBUG = True
但是,对于生产环境而言,这是一个非常糟糕的主意,因为它会泄露有关项目的大量信息:源代码的摘录,局部变量,设置,使用的库等。
特定于环境的设置
ALLOWED_HOSTS
那时,如果没有合适的值,Django根本无法工作。DEBUG = FalseALLOWED_HOSTS
需要此设置来保护您的站点免受某些CSRF攻击。如果使用通配符,则必须对HostHTTP标头执行自己的验证,否则,请确保您不容易受到此类攻击。
您还应该配置位于Django前面的Web服务器以验证主机。它应该以静态错误页面响应或忽略对不正确主机的请求,而不是将请求转发给Django。这样,您将避免在Django日志(或电子邮件(如果您以这种方式配置了错误报告)中)出现虚假错误。例如,在nginx上,您可以设置默认服务器以在无法识别的主机上返回“ 444 No Response”:
server { listen 80 default_server; return 444; }
CACHES
如果您使用缓存,则连接参数在开发和生产中可能会有所不同。Django默认对每个进程进行本地内存缓存,这可能是不希望的。
缓存服务器通常具有弱认证。确保它们仅接受来自您的应用程序服务器的连接。
DATABASES
数据库连接参数在开发和生产中可能有所不同。
数据库密码非常敏感。您应该像保护他们一样 SECRET_KEY。
为了获得最大的安全性,请确保数据库服务器仅接受来自应用程序服务器的连接。
如果您尚未为数据库设置备份,请立即执行!
EMAIL_BACKEND和相关设置
如果您的站点发送电子邮件,则需要正确设置这些值。
默认情况下,Django从webmaster @ localhost和root @ localhost发送电子邮件。但是,某些邮件提供商拒绝来自这些地址的电子邮件。要使用其他发件人地址,请修改DEFAULT_FROM_EMAIL和 SERVER_EMAIL设置。
STATIC_ROOT和STATIC_URL
静态文件由开发服务器自动提供。在生产中,必须定义一个STATIC_ROOT目录,collectstatic将它们复制到该目录中 。
有关更多信息,请参见管理静态文件(例如,图像,JavaScript,CSS)。
MEDIA_ROOT和MEDIA_URL
媒体文件由您的用户上传。他们是不信任的!确保您的Web服务器从不尝试解释它们。例如,如果用户上传 .php文件,则Web服务器不应执行该文件。
现在是检查这些文件的备份策略的好时机。
HTTPS
任何允许用户登录的网站都应实施站点范围的HTTPS,以避免明文传输访问令牌。在Django中,访问令牌包括登录名/密码,会话cookie和密码重置令牌。(如果要通过电子邮件发送密码重置令牌,则无法做很多事情来保护它们。)
保护敏感区域(例如用户帐户或管理员)是不够的,因为HTTP和HTTPS使用相同的会话cookie。您的网络服务器必须将所有HTTP通信重定向到HTTPS,并且只能将HTTPS请求传输到Django。
设置HTTPS后,请启用以下设置。
CSRF_COOKIE_SECURE
进行设置True以避免在HTTP上意外传输CSRF cookie。
SESSION_COOKIE_SECURE
进行设置True以避免在HTTP上意外传输会话cookie。
性能优化
设置将禁用仅在开发中有用的几个功能。此外,您可以调整以下设置。DEBUG = False
会话
考虑使用缓存的会话来提高性能。
如果使用数据库支持的会话,请定期清除旧会话,以避免存储不必要的数据。
CONN_MAX_AGE
如果在请求处理时间的很大一部分时间内连接到数据库帐户,则启用持久性数据库连接可以大大提高速度。
这对网络性能有限的虚拟主机有很大帮助。
TEMPLATES
启用缓存的模板加载器通常会大大提高性能,因为它避免了每次需要渲染每个模板时都对它们进行编译。有关更多信息,请参见 模板加载器文档。
错误报告
当您将代码推向生产时,它有望变得健壮,但不能排除意外错误。值得庆幸的是,Django可以捕获错误并相应地通知您。
LOGGING
在将网站投入生产之前,请查看日志记录配置,并在收到一些流量后立即检查它是否按预期工作。
有关日志记录的详细信息,请参见日志记录。
ADMINS和MANAGERS
ADMINS 将通过电子邮件通知500个错误。
MANAGERS将会收到404错误的通知。 IGNORABLE_404_URLS可以帮助过滤掉虚假报告。
有关通过电子邮件报告错误的详细信息,请参见错误报告。
通过电子邮件报告的错误无法很好地扩展
在您的收件箱被报告淹没之前,请考虑使用诸如Sentry之类的错误监视系统。哨兵也可以汇总日志。
自定义默认错误视图
Django包含一些HTTP错误代码的默认视图和模板。您可能希望通过在根模板目录中创建以下模板来覆盖缺省模板:404.html,500.html,403.html,和 400.html。使用这些模板的默认错误视图足以满足99%的Web应用程序的要求,但是您也可以对其进行 自定义。
详情参考: https://docs.djangoproject.com/en/3.0/
更多建议: