codecamp

部署清单

部署清单

互联网是一个敌对的环境。在部署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/


错误报告
Django 的安全性
温馨提示
下载编程狮App,免费阅读超1000+编程语言教程
取消
确定
目录

无标题目录

关闭

MIP.setData({ 'pageTheme' : getCookie('pageTheme') || {'day':true, 'night':false}, 'pageFontSize' : getCookie('pageFontSize') || 20 }); MIP.watch('pageTheme', function(newValue){ setCookie('pageTheme', JSON.stringify(newValue)) }); MIP.watch('pageFontSize', function(newValue){ setCookie('pageFontSize', newValue) }); function setCookie(name, value){ var days = 1; var exp = new Date(); exp.setTime(exp.getTime() + days*24*60*60*1000); document.cookie = name + '=' + value + ';expires=' + exp.toUTCString(); } function getCookie(name){ var reg = new RegExp('(^| )' + name + '=([^;]*)(;|$)'); return document.cookie.match(reg) ? JSON.parse(document.cookie.match(reg)[2]) : null; }