如何在我的所有项目中实施我自己的托管在远程域上的 CMS？
How to implement my own CMS hosted on a remote domain in all my projects?
因此，我正在开发自己的 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 文件分别上传到每个域，即使我只是更改一些小的东西。
我不知道这是否可以与 API 相比，例如 Google 地图 API 或其他只包含远程文件的东西？ （据我所知）
我有哪些选择？如果没有其他选择，我是否应该重新考虑使用 allow_url_fopen 但实施安全方法以避免攻击等？
1.) 不要这样做。
每个站点都应该有独立的库。想象一下，有一天您决定在您的 一个 站点中添加一项新功能或更改 CMS 中的一项功能。突然之间，您必须先在 所有 站点上测试此更改，然后才能推出。最好对所有文件进行版本控制，然后在可行时将这些文件部署到每个站点。
2.) 如果您 必须 这样做，并且您的托管服务提供商有一个文件 space 适用于您的所有域，您可以这样做，没问题。
例如，创建一个如下所示的文件结构：
~/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/' );
我的回答基于以下假设：
- 您对您的服务器具有某种根访问权限，并且您可以输入您的网络服务器的配置。
- 您在基于 web 的开发方面的经验很低（从事实推断，您构建了自己的 CMS；
allow_url_fopen 对您来说似乎是一个可行的选择，除此之外 allow_url_include 're actually seeking for; allow_url_include 不会神奇地连接到远程服务器并像服务器端一样加载 php 文件；由于安全风险，allow_url_include 绝对应该被禁用； allow_url_include 也可能会大大降低项目的性能；您关于什么是网络服务的想法来自 Google 地图 API) - 无意冒犯！
让我来解决 allow_url_fopen 和 allow_url_include 的问题：
allow_url_fopen和allow_url_include会要求你打开一个潜在的安全风险。：
allow_url_* 会要求您通过 http 公开应用程序的源代码。根据我推断的假设，你是初学者，我暗示潜在的攻击者会找到一种方法，如何很容易地制定一些黑客攻击的风险。不公平的概括，但当我查看年轻开发人员的源代码时，情况几乎总是如此。- 您的应用程序将有第二个可能被黑客攻击的层，它可以发出各种 php 代码。
- 您有一个额外的链条部件，可能会因维护或 hardware-/software-problems 而停机。当通过网络服务（REST 等）访问内容时也是如此。
allow_url_fopen 和 allow_url_include，甚至网络服务都可能会显着降低 CMS 的性能，因为所有受包含影响的文件都将通过网络流式传输，而不是（通常更好的连接）本地存储。
解决方案 1) 最常见的解决方案是，将您域的 DNS A 和 AAAA 记录配置为指向同一个服务器 IP，并配置您的网络服务器（例如 apache，nginx/varnish）以指向所有到单个虚拟主机的流量。然后，您的 CMS 必须处理来自不同 源地址 的请求。您可以根据超全局 $_SERVER['HTTP_HOST'] 变量中的内容提供适当的内容。请注意，如果您的服务器环境位于反向代理后面，则此变量的名称可能不同（您会知道这一点；那么每个访问者都没有不同）。
- 第一步：DNS解析：你的项目-a.xyz指向你的cms服务器的ip。
- 第 2 步：您的网络服务器知道，它必须对项目做一些事情-a.xyz
- 第 3 步：您的网络服务器将请求定向到您的 CMS
- Step4：您的CMS从
$_SERVER['HTTP_HOST'] 解析实际请求的主机
- 第 5 步：您的 CMS 发出属于请求的主机名的内容
解决方案 2) 如果您希望这些项目按照您的要求在物理上分开，您可以查看各种部署系统，这将使您能够将更改推送到多个目的地。您的 CMS 应该以一种方式构建，以不同方式处理 cm-system-core-files（PHP-Files）和实际内容，并且能够在不影响内容的情况下更新核心文件。你在这里没有太多选择。您可以使用 Git 或 SVN 之类的 SCM 系统轻松地与远程项目同步更改，但不鼓励这样做。
解决方案 3) 您确实可以构建某种网络服务（REST 是当今常用的技术）。因此，托管在 project-a.zyx 上的 Web 项目将是一个相当简单的瘦客户端，主要将请求重定向到某个 rest-endpoint。您通常还需要某种基于 https 的身份验证。这将要求您的客户端能够通过 HTTP（有时在共享托管环境中被禁用）从另一个端点请求内容（不是实际的源代码！），可选择对该内容进行一些转换并发出它。由于您的要求似乎暗示这不是理想的选择，因此您真的应该研究第一个解决方案。
因此，我正在开发自己的 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 文件分别上传到每个域，即使我只是更改一些小的东西。
我不知道这是否可以与 API 相比，例如 Google 地图 API 或其他只包含远程文件的东西？ （据我所知）
我有哪些选择？如果没有其他选择，我是否应该重新考虑使用 allow_url_fopen 但实施安全方法以避免攻击等？
1.) 不要这样做。
每个站点都应该有独立的库。想象一下，有一天您决定在您的 一个 站点中添加一项新功能或更改 CMS 中的一项功能。突然之间，您必须先在 所有 站点上测试此更改，然后才能推出。最好对所有文件进行版本控制，然后在可行时将这些文件部署到每个站点。
2.) 如果您 必须 这样做，并且您的托管服务提供商有一个文件 space 适用于您的所有域，您可以这样做，没问题。 例如，创建一个如下所示的文件结构：
~/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/' );
我的回答基于以下假设：
- 您对您的服务器具有某种根访问权限，并且您可以输入您的网络服务器的配置。
- 您在基于 web 的开发方面的经验很低（从事实推断，您构建了自己的 CMS；
allow_url_fopen对您来说似乎是一个可行的选择，除此之外allow_url_include're actually seeking for;allow_url_include不会神奇地连接到远程服务器并像服务器端一样加载 php 文件；由于安全风险，allow_url_include绝对应该被禁用；allow_url_include也可能会大大降低项目的性能；您关于什么是网络服务的想法来自 Google 地图 API) - 无意冒犯！
让我来解决 allow_url_fopen 和 allow_url_include 的问题：
allow_url_fopen和allow_url_include会要求你打开一个潜在的安全风险。：allow_url_*会要求您通过 http 公开应用程序的源代码。根据我推断的假设，你是初学者，我暗示潜在的攻击者会找到一种方法，如何很容易地制定一些黑客攻击的风险。不公平的概括，但当我查看年轻开发人员的源代码时，情况几乎总是如此。- 您的应用程序将有第二个可能被黑客攻击的层，它可以发出各种 php 代码。
- 您有一个额外的链条部件，可能会因维护或 hardware-/software-problems 而停机。当通过网络服务（REST 等）访问内容时也是如此。
allow_url_fopen和allow_url_include，甚至网络服务都可能会显着降低 CMS 的性能，因为所有受包含影响的文件都将通过网络流式传输，而不是（通常更好的连接）本地存储。
解决方案 1) 最常见的解决方案是，将您域的 DNS A 和 AAAA 记录配置为指向同一个服务器 IP，并配置您的网络服务器（例如 apache，nginx/varnish）以指向所有到单个虚拟主机的流量。然后，您的 CMS 必须处理来自不同 源地址 的请求。您可以根据超全局 $_SERVER['HTTP_HOST'] 变量中的内容提供适当的内容。请注意，如果您的服务器环境位于反向代理后面，则此变量的名称可能不同（您会知道这一点；那么每个访问者都没有不同）。
- 第一步：DNS解析：你的项目-a.xyz指向你的cms服务器的ip。
- 第 2 步：您的网络服务器知道，它必须对项目做一些事情-a.xyz
- 第 3 步：您的网络服务器将请求定向到您的 CMS
- Step4：您的CMS从
$_SERVER['HTTP_HOST']解析实际请求的主机
- 第 5 步：您的 CMS 发出属于请求的主机名的内容
解决方案 2) 如果您希望这些项目按照您的要求在物理上分开，您可以查看各种部署系统，这将使您能够将更改推送到多个目的地。您的 CMS 应该以一种方式构建，以不同方式处理 cm-system-core-files（PHP-Files）和实际内容，并且能够在不影响内容的情况下更新核心文件。你在这里没有太多选择。您可以使用 Git 或 SVN 之类的 SCM 系统轻松地与远程项目同步更改，但不鼓励这样做。
解决方案 3) 您确实可以构建某种网络服务（REST 是当今常用的技术）。因此，托管在 project-a.zyx 上的 Web 项目将是一个相当简单的瘦客户端，主要将请求重定向到某个 rest-endpoint。您通常还需要某种基于 https 的身份验证。这将要求您的客户端能够通过 HTTP（有时在共享托管环境中被禁用）从另一个端点请求内容（不是实际的源代码！），可选择对该内容进行一些转换并发出它。由于您的要求似乎暗示这不是理想的选择，因此您真的应该研究第一个解决方案。