Question

所以，我正在开发自己的CMS，它会动态调整到我在特定域上设置的设置。

我刚刚在我的本地计算机上开发了这个整个CMS，现在面临的问题是我有多个项目，每个项目都在不同的域名（相同的主机提供商，但不知道这是否相关？）。在我的本地主机上没问题，因为我只是指向特定的CMS文件夹。

__

示例：我的CMS文件位于 www.mycms.com 的子目录中，如www.mycms.com/cms/，我的项目位于 www.project-a.com

现在我假设我只需要包含我的多个CMS文件，例如www.mycms.com/cms/classes/user.php等。

由于这会给我一个permission denied错误，因为存在安全风险，网络上的每个人似乎都反对allow_url_fopen，我需要知道我是否还有其他可能性来完成这项工作每次/cms/到每个域的文件。因为这会迫使我将所有CMS文件一直上传到每个域，即使我只是改变了一些小事情。

我不知道这是否与Google Maps API之类的API相比，或者您还只包含远程文件？（据我所知）

我有什么选择？如果没有选项，我是否应该重新考虑使用allow_url_fopen但是实施安全方法以避免攻击等？

Answer 1

我的回答基于以下假设：

您可以对服务器进行root访问，并且可以输入网络服务器的配置。
您在基于网络的开发方面经验相当低（从事实证明，您构建自己的CMS; allow_url_fopen似乎是一个可行的选择，除此之外allow_url_include就是您所拥有的实际上寻求; allow_url_include不会神奇地连接到远程服务器并加载像服务器端这样的php文件;由于安全风险，肯定会禁用allow_url_include; allow_url_include可以还会大大降低项目的性能;您对什么是Web服务的想法来自Google Maps API） - 无意冒犯！

让我解决allow_url_fopen和allow_url_include：

的问题

allow_url_fopen和allow_url_include会要求您开启潜在的安全风险：
- allow_url_*会要求您通过http公开您的应用程序的源代码。基于我推断的假设，你是初学者，我暗示风险，潜在的攻击者会找到一种方法，如何制定一些黑客非常容易。不公平的概括，但在我审查年轻开发人员的源代码时几乎总是如此。
- 你的应用程序的第二个可能是可以破解的层，它可以发出各种各样的php代码。
您有一个额外的链条部件，可能因维护或硬件/软件问题而导致停机。在通过Web服务（REST等）访问内容时也是如此。
allow_url_fopen和allow_url_include，甚至是网络服务都可能会显着降低CMS的性能，因为所有受到包含的文件都会通过网络流式传输而不是（通常更好）连接）本地存储。

解决方案1）最常见的解决方案是，将您的域的DNS A和AAAA-Records配置为指向同一服务器-ip并配置您的网络服务器（例如apache，nginx / varnish）以将所有流量指向单个虚拟主机。然后，您的CMS必须处理来自不同原始地址的请求。您可以根据超全局$_SERVER['HTTP_HOST']变量中的内容提供相应的内容。请注意，如果您的服务器环境位于reverseeproxy后面，则此变量的名称可能会有所不同（您可能知道这一点;然后每个访问者的情况并没有不同）。

步骤1：DNS解析：您的project-a.xyz指向您的cms服务器的IP。
第2步：您的网络服务器知道它必须使用project-a.xyz
第3步：您的网络服务器将请求定向到您的CMS
步骤4：您的CMS从$_SERVER['HTTP_HOST']
步骤5：您的CMS会发出属于所请求主机名的内容

解决方案2）如果您希望这些项目按照您的请求建议进行物理分离，您可以查看各种部署系统，这些系统可以将更改推送到多个目标。您的CMS应该以某种方式构建，以不同方式处理cm-system-core-files（PHP-Files）和实际内容，并且能够在不影响内容的情况下更新核心文件。你这里没有太多选择。您可以使用像Git或SVN这样的SCM系统轻松地同步远程项目的更改，但这是相当不鼓励的。

解决方案3）您确实可以构建某种Web服务（REST是目前常用的技术）。因此，在project-a.zyx上托管的web项目将是一个相当简单的瘦客户端，它主要将请求重定向到某些休息端点。您通常还需要某种基于https的身份验证。这将要求您的客户端能够通过HTTP（有时在共享托管环境中禁用）从另一个端点请求内容（而不是实际的源代码！），可选地对该内容进行一些转换并发出它。由于您的请求似乎意味着，这不是理想的选择，您应该真正研究第一个解决方案。

Answer 2

1。）不要这样做。

每个站点都应该有独立的库。想象一下，有一天您决定进行更改以添加新功能或更改CMS中一个您的网站的功能。突然之间，您必须在所有网站上测试此更改，然后才能推出它。最好对所有文件进行版本控制，然后将这些文件部署到每个站点，因为这样做是可行的。

2。）如果您必须这样做，并且您的托管服务提供商为您的所有域都有一个文件空间，那么您可以这样做，没问题。例如，创建一个看起来像的文件结构：

~/public_html/cms/
~/public_html/project-a.com/
~/public_html/project-b.com/
…

对于每个网站（仅在该网站的配置文件中，或者如果所有流量路由都通过index.php）：

define( ‘CMS_PATH’, /root/path/to/users/your-user-name/public_html/cms/‘ );

现在每个站点都可以访问CMS文件：

require CMS_PATH . ‘classes/user.php’;

您也可以在这里获得一点点聪明，这样您就不必手动定义每个站点的路径。如果您在文件~/public_html/project-a.com/index.php中定义它，则可以使用

define( ‘CMS_PATH’, dirname(dirname(__FILE__)) . '/cms/' );

如何在我的所有项目中实现托管在远程域上的自己的CMS？

2 个答案: