十三、公共和非公共资源分开

至此，我们在重组遗留应用程序的核心方面取得了重大进展。然而，周围的建筑仍有许多不足之处。

除此之外，我们的整个应用程序仍然嵌入在文档根中。这意味着，我们需要对我们打算保密的资源进行特殊保护，或者我们需要依靠隐蔽性来确保客户不会浏览到不打算公开的资源。web 服务器配置中的错误或未能注意到特定的安全措施，可能会将我们的部分应用程序泄露给公众。

因此，我们的下一步是将所有公共资源提取到新的文档根目录中。这将防止意外交付非公共资源，并为进一步重构建立一个结构。

目前，我们的 web 服务器充当传统应用程序的组合前端控制器、路由器和调度器。页面脚本的路由直接映射到文件系统，使用 web 服务器文档根作为基础。反过来，web 服务器文档根目录直接映射到遗留应用程序的根目录。

例如，如果 web 服务器文档根为/var/www/htdocs，则它当前将作为应用程序根加倍。因此，URL 路径/foo/bar.php直接映射到/var/www/htdocs/foo/bar.php。

对于公共资源来说，这可能很好，但我们的应用程序中有很大一部分不希望外部人员直接访问。例如，与配置和设置相关的目录不应暴露于可能的外部检查。web 服务器配置中的错误可能会泄露代码本身，使恶意用户可以使用我们的密码和其他信息。

虽然过程本身很简单，但我们正在进行的变革是一项基础性的变革。它影响服务器配置以及遗留应用程序结构。为了完全实现此更改，我们需要与负责服务器部署的所有操作人员密切协调。

一般来说，流程如下：

1. 与运营部协调，传达我们的意图。


2. 在遗留应用程序中创建一个新的文档根目录以及一个临时索引文件。


3. 重新配置服务器以指向新的文档根目录，并抽查新配置以查看是否显示临时索引文件。


4. 删除临时索引文件，然后将所有公共资源移动到新文档根目录，并在此过程中进行抽查。


5. 提交、推动和协调 QA 测试的操作。

与操作人员协调

这是这个过程中最重要的一步。在未与服务器负责人（我们的操作人员）讨论我们的意图之前，我们决不能做出影响服务器配置的更改。

运营部门的反馈将告知我们需要遵循的路径，以确保我们的变革有效。他们将建议或指导我们新文档根目录名应该是什么，以及新服务器配置指令应该是什么。他们负责部署应用程序，因此我们希望尽最大努力使他们的工作尽可能简单。如果运营不愉快，那么每个人都会不高兴。

或者，如果我们没有操作人员，并且负责自己的部署，那么我们的工作就会变得越来越容易。这更容易，因为我们没有协调和沟通成本。这更难，因为我们需要关于服务器配置的具体、详细的知识。在这种情况下，请小心操作。

创建文档根目录

在与我们的操作人员协调之后，我们在遗留应用程序结构中创建了一个文档根目录。我们的运营联系人将向我们提供正确的目录名；在本例中，我们假设名称为docroot/。

例如，如果我们当前有一个如下所示的遗留应用程序结构：

var/www/htdocs/

classes/
...
css/
...
foo/
bar/
baz.php
images/
...
includes/
...
index.php
js/
tests/
...
views/
...


... 我们在应用程序的顶层添加了一个新的docroot/目录。在新文档根目录中，我们添加了一个临时index.html文件。这将让我们知道，如果我们的服务器重新配置工作正常。它可以包含我们喜欢的任何文本，例如Rejoice! The new configuration works!。

完成后，新的目录结构将看起来更像这样：

/var/www/htdocs/

classes/
...
css/
...
docroot/
index.html
foo/
bar/
baz.php
images/
...
includes/
...
index.php
js/
...
tests/
...
views/
...


重新配置服务器

现在，我们重新配置本地开发 web 服务器，以指向新的docroot/目录。我们的操作人员应该给我们一些如何操作的指示。

在 Apache 中，我们可以编辑本地开发环境的配置文件，以更改主应用程序目录中相关.conf文件中的DocumentRoot指令：

DocumentRoot "/var/www/htdocs"


... 到应用程序中新创建的子目录：

DocumentRoot "/var/www/htdocs/docroot"


然后保存文件，重新加载或重启服务器以应用更改。

提示

适用的DocumentRoot指令可能位于多个位置之一。它可以在主httpd.conf文件中，也可以作为VirtualHost指令的一部分在单独的配置文件中。如果我们使用的不是 Apache，那么配置可能位于完全不同的文件中。不幸的是，关于 web 服务器管理的完整说明超出了本书的范围。有关详细信息，请查看特定服务器的文档。

一旦应用了配置更改，我们将浏览到遗留应用程序，查看新文档根是否得到尊重。我们应该看看我们临时index.html文件的内容。如果没有，我们就做错了，需要重新审视我们的变化，直到它们按预期工作为止。

移动公共资源

既然我们已经将 web 服务器配置为指向我们新的docroot/目录，我们就可以安全地删除我们的临时index.html文件。

这样做之后，我们的下一步是将所有公共资源从其当前位置移动到新的docroot/目录中。这包括我们所有的页面脚本、样式表、Javascript 文件、图像等。它不包括用户不能浏览的任何内容：类、包含、设置、配置、命令行脚本、测试、查看文件等等。

我们希望在docroot/中保持与在应用程序基础中相同的相对位置，因此在移动时不应更改文件名或目录名。

当我们将公共资源移动到新位置时，我们应该偶尔通过浏览应用程序来抽查修改后的结构。这将有助于我们尽早发现更改中的任何问题，而不是推迟。

提示

我们移动的一些 PHP 文件可能仍然依赖于特定位置的include文件。在这些情况下，我们可能需要修改它们以指向相对于新的docroot/目录的路径。或者，我们可能需要修改 include 路径值，以便它们可以找到必要的文件。

完成后，我们将有一个目录结构，看起来更像这样：

/var/www/htdocs/

classes/
...
docroot/
css/
...
foo/
bar/
baz.php
index.php
js/
...
images/
...
includes/
...
tests/
...
views/
...


提交、推送、协调

当我们将所有公共资源移动到新的docroot/目录，并且遗留应用程序在此新结构中正常工作时，我们提交所有更改并将它们推送到公共存储库。

此时，我们通常会通知 QA 我们对测试的更改。但是，由于我们已经对服务器配置进行了基础性更改，因此我们需要与操作人员协调 QA 测试。运营部门可能需要将新配置部署到 QA 服务器。只有这样，QA 才能有效地检查我们的工作。

这真的有必要吗？

大多数情况下，将各种非公共资源留在文档根目录中似乎是无害的。但是对于我们的下一步，将公共资源和非公共资源分开是非常重要的。

我们现在已经开始重构遗留应用程序的总体架构。通过创建将公共资源与非公共资源分开的文档根，我们可以开始构建一个前端控制器系统来控制对应用程序的访问。