目录
当前,我们部署的项目存在一个严重的安全问题:settings.py包含设置DEBUG=True,它在发生错误时显示调试信息。开发项目时,Django的错误页面向你显示了重要的调试信息,如果将项目 部署到服务器后依然保留这个设置,将给攻击者提供大量可供利用的信息。我们还需确保任何人 都无法看到这些信息,也不能冒充项目托管网站来重定向请求。 下面来修改settings.py,以让我们能够在本地看到错误消息,但部署到服务器后不显示任何 错误消息:
settings.py
--snip--
# Heroku设置
if os.getcwd() == '/app':
--snip--
# 让request.is_secure()承认X-Forwarded-Proto头
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
# 只允许Heroku托管这个项目
1 ALLOWED_HOSTS = ['learning-log.herokuapp.com']
2 DEBUG = False
# 静态资产配置
--snip--
我们只需做两方面的修改。在1处,修改ALLOWED_HOSTS,只允许Heroku托管这个项目。你需 要使用应用程序的名称,可以是Heroku提供的名称(如afternoon-meadow-2775.herokuapp.com), 也可以是你选择的名称。在2处,我们将DEBUG设置为False,让Django不在错误发生时显示敏感 信息。
现在需要将对settings.py所做的修改提交到Git仓库,再将修改推送到Heroku。下面的终端会 话演示了这个过程:
1 (ll_env)learning_log$ git commit -am "Set DEBUG=False for Heroku."
[master 081f635] Set DEBUG=False for Heroku.
1 file changed, 4 insertions(+), 2 deletions(-)
2 (ll_env)learning_log$ git status
# On branch master
nothing to commit, working directory clean
(ll_env)learning_log$
我们执行命令git commit,并指定了一条简短而具有描述性的提交消息(见1)。别忘了,标 志-am让Git提交所有修改过的文件,并记录一条日志消息。Git找出唯一一个修改过的文件,并将 所做的修改提交到仓库。
2处显示的状态表明我们在仓库的分支master上工作,当前没有任何未提交的修改。推送到Heroku之前,必须检查状态并看到刚才所说的消息。如果你没有看到这样的消息,说明有未提交 的修改,而这些修改将不会推送到服务器。在这种情况下,可尝试再次执行命令commit,但如果 你不知道该如何解决这个问题,请阅读附录D,更深入地了解Git的用法。 下面来将修改后的仓库推送到Heroku:
(ll_env)learning_log$ git push heroku master
--snip--
remote: -----> Python app detected
remote: -----> Installing dependencies with pip
--snip--
remote: -----> Launching... done, v8
remote: https://learning-log.herokuapp.com/ deployed to Heroku
remote: Verifying deploy.... done.
To https://git.heroku.com/learning-log.git
4c9d111..ef65d2b master -> master
(ll_env)learning_log$
Heroku发现仓库发生了变化,因此重建项目,确保所有的修改都已生效。它不会重建数据库, 因此这次无需执行命令migrate。 现在要核实部署更安全了,请输入项目的URL,并在末尾加上我们未定义的扩展。例如,尝 试访问http://learning-log.herokuapp.com/letmein/。你将看到一个通用的错误页面,它没有泄露任 何有关该项目的具体信息。如果你尝试向本地的“学习笔记”发出同样的请求——输入URL http://localhost:8000/letmein/,你将看到完整的Django错误页面。这样的结果非常理想,你接着开 发这个项目时,将看到信息丰富的错误消息,但用户看不到有关项目代码的重要信息。
在第19章,我们对“学习笔记”进行了配置,使其在用户请求不属于他的主题或条目时返回 404错误。你可能还遇到过一些500错误(内部错误)。404错误通常意味着你的Django代码是正确 的,但请求的对象不存在。500错误通常意味着你编写的代码有问题,如views.py中的函数有问题。 当前,在这两种情况下,Django都返回通用的错误页面,但我们可以编写外观与“学习笔记”一 致的404和500错误页面模板。这些模板必须放在根模板目录中。
1. 创建自定义模板
在文件夹learning_log/learning_log中,新建一个文件夹,并将其命名为templates;再在这个 文件夹中新建一个名为404.html的文件,并在其中输入如下内容:
404.html
{% extends "learning_logs/base.html" %}
{% block header %}
<h2>The item you requested is not available. (404)</h2>
{% endblock header %}
这个简单的模板指定了通用的404错误页面包含的信息,并且该页面的外观与网站的其他部 分一致。 再创建一个名为500.html的文件,并在其中输入如下代码:
500.html
{% extends "learning_logs/base.html" %}
{% block header %}
<h2>There has been an internal error. (500)</h2>
{% endblock header %}
这些新文件要求对settings.py做细微的修改:
settings.py
--snip--
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'learning_log/templates')],
'APP_DIRS': True,
--snip--
},
]
--snip-
这项修改让Django在根模板目录中查找错误页面模板。
2. 在本地查看错误页面
在将项目推送到Heroku之前,如果你要在本地查看错误页面是什么样的,首先需要在本地设 置中设置Debug=False,以禁止显示默认的Django调试页面。为此,可对settings.py做如下修改(请 确保你修改的是用于本地环境的settings.py部分,而不是用于Heroku的部分):
settings.py
--snip--
# 安全警告:不要在在线环境中启用调试!
DEBUG = False
ALLOWED_HOSTS = ['localhost']
--snip--
DEBUG被设置为False时,你必须在ALLOWED_HOSTS中指定一个主机。现在,请求一个不属于你 的主题或条目,以查看404错误页面;请求不存在的URL(如localhost:8000/letmein/),以查看500 错误页面。 查看错误页面后,将DEBUG重新设置为True,以方便你进一步开发“学习笔记”。(在settings.py 中用于Heroku部署的部分中,确保DEBUG依然被设置为False)。
500错误页面不会显示任何有关当前用户的信息,因为发生服务器错误时,Django不会通 过响应发送任何上下文信息。
3. 将修改推送到Heroku
现在需要提交对模板所做的修改,并将这些修改推送到Heroku
1 (ll_env)learning_log$ git add .
2 (ll_env)learning_log$ git commit -am "Added custom 404 and 500 error pages."
3 files changed, 15 insertions(+), 10 deletions(-)
create mode 100644 learning_log/templates/404.html
create mode 100644 learning_log/templates/500.html
3 (ll_env)learning_log$ git push heroku master
--snip--
remote: Verifying deploy.... done.
To https://git.heroku.com/learning-log.git
2b34ca1..a64d8d3 master -> master
(ll_env)learning_log$
在1处,我们执行了命令git add,这是因为我们在项目中创建了一些新文件,因此需要让 Git跟踪这些文件。然后,我们提交所做的修改(见2),并将修改后的项目推送到Heroku(见3)。 现在,错误页面出现时,其样式应该与网站的其他部分一致,这样在发生错误时,用户将不 会感到突兀。
4. 使用方法get_object_or_404() 现在,如果用户手工请求不存在的主题或条目,将导致500错误。Django尝试渲染请求的页 面,但没有足够的信息来完成这项任务,进而引发500错误。对于这种情形,将其视为404错误更 合适,为此可使用Django快捷函数get_object_or_404()。这个函数尝试从数据库获取请求的对象, 如果这个对象不存在,就引发404异常。我们在views.py中导入这个函数,并用它替换函数get():
views.py
--snip--
from django.shortcuts import render, get_object_or_404
from django.http import HttpResponseRedirect, Http404
--snip--
@login_required
def topic(request, topic_id):
"""显示单个主题及其所有的条目"""
topic = get_object_or_404(Topic, id=topic_id)
# 确定主题属于当前用户
--snip--
现在,如果你请求不存在的主题(例如,使用URL http://localhost:8000/topics/999999/),将 看到404错误页面。为部署这里所做的修改,再次提交,并将项目推送到Heroku。
将项目“学习笔记”推送到服务器后,你可能想进一步开发它或开发要部署的其他项目。更 新项目的过程几乎完全相同。
首先,你对本地项目做必要的修改。如果在修改过程中创建了新文件,使用命令git add . (千万别忘记这个命令末尾的句点)将它们加入到Git仓库中。如果有修改要求迁移数据库,也需 要执行这个命令,因为每个迁移都将生成新的迁移文件。
然后,使用命令git commit -am "commit message"将修改提交到仓库,再使用命令git push heroku master将修改推送到Heroku。如果你在本地迁移了数据库,也需要迁移在线数据库。为 此,你可以使用一次性命令heroku run python manage.py migrate,也可使用heroku run bash打 开一个远程终端会话,并在其中执行命令python manage.py migrate。然后访问在线项目,确认 你期望看到的修改已生效。
在这个过程中很容易犯错,因此看到错误时不要大惊小怪。如果代码不能正确地工作,请重 新审视所做的工作,尝试找出其中的错误。如果找不出错误,或者不知道如何撤销错误,请参阅 附录C中有关如何寻求帮助的建议。不要羞于去寻求帮助:每个学习开发项目的人都可能遇到过 你面临的问题,因此总有人乐意伸出援手。通过解决遇到的每个问题,可让你的技能稳步提高, 最终能够开发可靠而有意义的项目,还能解决别人遇到的问题。