互联网是一个恶略的环境。 在部署Django项目之前,您应该花一些时间审查您的设置,并考虑安全性,性能和操作。
Django包含许多security features。 有些是内置的,总是启用。 其他是可选的,因为它们不总是适当的,或者因为它们不便于开发。 例如,强制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 = 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,这可能是不可取的。
缓存服务器通常具有弱认证。 确保它们只接受来自应用程序服务器的连接。
如果您使用Memcached,请考虑使用cached sessions来提高性能。
DATABASES
¶数据库连接参数在开发和生产中可能有所不同。
数据库密码非常敏感。 您应该像SECRET_KEY
完全保护他们。
为了最大的安全性,请确保数据库服务器只接受来自应用程序服务器的连接
如果您尚未为数据库设置备份,请立即执行!
STATIC_ROOT
和STATIC_URL
¶静态文件由开发服务器自动提供。 在生产中,您必须定义STATIC_ROOT
目录,其中collectstatic
将复制它们。
有关更多信息,请参阅 管理静态文件(例如图片,JavaScript,CSS)。
MEDIA_ROOT
和MEDIA_URL
¶媒体文件由用户上传。 他们不受信任! 确保您的Web服务器从不尝试解释它们。 例如,如果用户上传.php
文件,则Web服务器不应执行。
现在是检查这些文件的备份策略的好时机。
允许用户登录的任何网站都应执行站点范围的HTTPS,以避免传输访问令牌。 在Django中,访问令牌包括登录/密码,会话cookie和密码重置令牌。 (如果您通过电子邮件发送密码重置令牌,则无法执行太多操作。)
保护敏感区域(例如用户帐户或管理员)是不够的,因为相同的会话cookie用于HTTP和HTTPS。 您的网络服务器必须将所有HTTP流量重定向到HTTPS,并且只传输HTTPS请求到Django。
设置HTTPS后,请启用以下设置。
CSRF_COOKIE_SECURE
¶将此设置为True
可避免意外传输HTTP上的CSRF Cookie。
SESSION_COOKIE_SECURE
¶将此设置为True
可避免意外地通过HTTP传输会话Cookie。
设置DEBUG = False
禁用仅在开发中有用的几个功能。 此外,您可以调整以下设置。
TEMPLATES
¶启用缓存模板加载器通常会大幅提高性能,因为它避免在每次需要渲染时编译每个模板。 有关详细信息,请参阅template loaders docs。
当你把你的代码推向生产,它希望是强大的,但你不能排除意外的错误。 幸运的是,Django可以捕获错误,并据此通知您。
ADMINS
和MANAGERS
¶ADMINS
将通过电子邮件通知500个错误。
MANAGERS
将通知404错误。
IGNORABLE_404_URLS
可以帮助滤除虚假报告。
有关通过电子邮件报告错误的详细信息,请参阅Error reporting。
电子邮件错误报告不能很好地缩放
考虑使用错误监控系统,例如Sentry,然后您的收件箱被报告淹没。 Sentry也可以聚合日志。
Django包括多个HTTP错误代码的默认视图和模板。 您可能希望通过在根模板目录中创建以下模板来覆盖默认模板:404.html
, 500.html
,403.html
,和 400.html
。 默认视图应足以满足99%的Web应用程序,但如果您希望自定义它们,请参阅这些说明,其中还包含有关默认模板的详细信息:
强烈建议您使用-R选项或将 PYTHONHASHSEED
环境变量设置为random
。 默认情况下,此选项从Python 3.3开始启用。
这些选项有助于保护您的网站免受由精心设计的输入触发的拒绝服务(DoS)攻击。 当创建dict
实例时,这种攻击可能会导致最糟糕的性能,从而显着增加CPU使用率。 有关详细信息,请参阅oCERT咨询#2011-003。
2017年9月6日