关于“Python”的核心知识点整理大全64

20.2.15 确保项目的安全

当前，我们部署的项目存在一个严重的安全问题：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不在错误发生时显示敏感 信息。

20.2.16 提交并推送修改

现在需要将对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错误页面。这样的结果非常理想，你接着开 发这个项目时，将看到信息丰富的错误消息，但用户看不到有关项目代码的重要信息。

20.2.17 创建自定义错误页面

在第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。

20.2.18 继续开发

将项目“学习笔记”推送到服务器后，你可能想进一步开发它或开发要部署的其他项目。更 新项目的过程几乎完全相同。

首先，你对本地项目做必要的修改。如果在修改过程中创建了新文件，使用命令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中有关如何寻求帮助的建议。不要羞于去寻求帮助：每个学习开发项目的人都可能遇到过 你面临的问题，因此总有人乐意伸出援手。通过解决遇到的每个问题，可让你的技能稳步提高， 最终能够开发可靠而有意义的项目，还能解决别人遇到的问题。