如何在我的所有项目中实现托管在远程域上的自己的 CMS? [英] How to implement my own CMS hosted on a remote domain in all my projects?

问题描述

因此，我正在开发自己的 CMS，它会根据我在特定域上设置的设置进行动态调整.

So, I'm developing my own CMS which dynamically adjusts to the settings I have set on a specific domain.

我刚刚在我的本地机器上开发了整个 CMS，现在面临的问题是我有多个项目，每个项目都在不同的域上(虽然是同一个主机提供商，不知道这是否相关?).在我的本地主机上没有问题，因为我只是指向特定的 CMS 文件夹.

I just developed this whole CMS on my local machine and now facing the problem that I have multiple projects, each on a different domain (same host provider though, don't know if that's relevant?). On my localhost it's no problem because I just point to the specific CMS folder.

__

示例:我的 CMS 文件位于 www.mycms.com 的子目录中，例如 www.mycms.com/cms/，并且我的项目托管在 www.project-a.com.

Example: My CMS Files are in a subdirectory of www.mycms.com like www.mycms.com/cms/ and my project ist hosted on www.project-a.com.

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

Now I assumed I just need to include my multiple CMS files like www.mycms.com/cms/classes/user.php, etc.

由于这给我一个 permission denied 错误，并且网络上的每个人似乎都因为安全风险而反对 allow_url_fopen，我需要知道我是否有其他可能性无需每次都将 /cms/ 的所有文件放入每个域中即可完成此工作.因为这会迫使我一直将所有 CMS 文件单独上传到每个域，即使我只是更改一些小东西.

Since this gives me a permission denied error and everyone on the web seems to be against allow_url_fopen because of security risks, I need to know if I have other possibilities to make this work without putting all the files of /cms/ into each domain each time. Because that would force me to upload all CMS files all the time to each domain seperately, even if I just change minor things.

我不知道这是否可以与诸如 Google Maps API 之类的 API 或仅包含远程文件的 API 相提并论?(据我所知)

I don't know if this is compareable to an API like the Google Maps API or something where you also just include remote files? (As far as I know)

我有哪些选择?如果没有其他选择，我是否应该重新考虑使用 allow_url_fopen 但实施安全方法以避免攻击等?

What are my options? And if there are no options left, should I reconsider using allow_url_fopen but implementing security methods to avoid attacks, etc?

推荐答案

我的回答基于以下假设:

My answer is based on following assumptions:

• 您对服务器拥有根访问权限，并且可以输入网络服务器的配置.
• 您在基于 Web 的开发方面的经验相当少(根据您构建自己的 CMS 的事实推断；allow_url_fopen 对您来说似乎是一个可行的选择，除了 allow_url_include 是你真正想要的；allow_url_include 不会像服务器端那样神奇地连接到远程服务器并加载 php 文件；allow_url_include 绝对应该被禁用，由于安全风险；allow_url_include 也可能会大大降低您项目的性能；您对什么是网络服务的想法源自 Google Maps API) - 无意冒犯！

• You have kind of root-access to your server and you are able to enter your webserver's configuration.
• You have rather low experience in web-based development (deduced from the fact, that you build your own CMS; allow_url_fopen seems a viable option to you, beside that allow_url_include is what you're actually seeking for; allow_url_include won't magically connect to the remote server and load the php-files like server-side; allow_url_include should definitely be disabled, due to security risks; allow_url_include could also greatly reduce the performance of your project; your idea of what is a webservice is derived from Google Maps API) - no intent to offend!

让我解决 allow_url_fopen 和 allow_url_include 的问题:

Let me address the issues with allow_url_fopen and allow_url_include:

• allow_url_fopen 和 allow_url_include 将要求您打开潜在的安全风险.:
  • allow_url_* 将要求您通过 http 公开应用程序的源代码.根据我推断的假设，您是初学者，我暗示风险，潜在的攻击者会找到一种方法，如何非常容易地制定一些 hack.不公平的概括，但当我查看年轻开发者的源代码时，情况几乎总是如此.
  • 您的应用程序将有第二个潜在的可破解层，它可能会发出各种 php 代码.
  • allow_url_fopen and allow_url_include would require you to open a potential security risk.:
    • allow_url_* would require you to expose the source-code of your application via http. Based on my deduced assumption, that you're rather beginner, I imply the risk, that a potential attacker would find a way, how to formulate some hack very easy. Unfair generalization, but this is almost always the case when I review source-code of younger developers.
    • You will have a second, potentially hackable layer of your application, that could emit all sorts of php-code.

    解决方案 1) 最常见的解决方案是，将域的 DNS A 和 AAAA-Records 配置为指向相同的服务器 IP 并配置您的网络服务器(例如 apache、nginx/varnish)以将所有流量定向到单个虚拟主机.然后，您的 CMS 必须处理来自不同源地址的请求.您可以根据超级全局 $_SERVER['HTTP_HOST'] 变量中的内容提供适当的内容.请注意，如果您的服务器环境位于反向代理之后，则此变量的名称可能会有所不同(您会知道这一点；这对于每个访问者来说都没有不同).

    Solution 1) The most common solution is, to configure your domain's DNS A and AAAA-Records to point all to the same server-ip and configure your webserver (eg apache, nginx/varnish) to direct all traffic to a single virtual-host. Your CMS then has to deal with requests from different origin addresses. You can deliver the appropriate content based on, whats in the super-global $_SERVER['HTTP_HOST']-variable. Beware, that this variable could be named differently, if your server-environment is behind a reverseproxy (you would know this; this is not different per visitor then).

    • 步骤 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 系统轻松地将更改与远程项目同步，但不建议这样做.

    Solution 2) If you want those projects to be physically separated as your requests suggests, you can take a look at various deployment-systems, that would enable to you push changes to multiple destinations. Your CMS should be built in a way, that treats cm-system-core-files (PHP-Files) and actual content differently and is able to update core-files without affecting content. You don't have pretty much options here. You could use SCM-Systems like Git or SVN to sync changes with remote projects easily, but this is rather discouraged.

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

    Solution 3) You can indeed build some kind of webservice (REST is a often used technique these days). So the web-project hosted on project-a.zyx would be a rather simple thin-client, that mostly redirects requests to some rest-endpoint. You would normally also want some kind of https-based authentication here. This would require your clients to be able to request content (not actual source-code!) from another endpoint via HTTP (which is sometimes disabled on shared hosting environments), optionally make some transformation on that content and emit it. Since your requests seems to imply, that this is not the ideal option, you should really look into the first solution.

    这篇关于如何在我的所有项目中实现托管在远程域上的自己的 CMS?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！