在 PHP 级别保护文件的面向性能的方法? [英] Performance-oriented way to protect files on PHP level?

问题描述

我想就我一直在思考的事情寻找一些意见.这是一个非常普遍的问题，也许有一些我还没有想到的解决方案.

I am looking for some input on something I have been thinking about for a long time. It is a very general problem, maybe there are solutions out there I haven't thought of yet.

我有一个基于 PHP 的 CMS.
对于在 CMS 中创建的每个页面，用户都可以上传资产(要下载的文件、图片等)

I have a PHP-based CMS.
For each page created in the CMS, the user can upload assets (Files to download, Images, etc.)

这些资产存储在一个目录中，我们称之为/myproject/assets"，以每页为基础(1 个子目录 = 1 页，例如/myproject/assets/page19283")

Those assets are stored in a directory, let's call it "/myproject/assets", on a per-page basis (1 subdirectory = 1 page, e.g. "/myproject/assets/page19283")

用户可以在 CMS 中取消发布"(隐藏)页面.当某个页面被隐藏时，如果有人因为记住了 URL 或来自 Google 或其他东西而试图访问它，他们会收到未找到"消息.

The user can "un-publish" (hide) pages in the CMS. When a page is hidden, and somebody tries to access it because they have memorized the URL or they come from Google or something, they get a "Not found" message.

但是，资产仍然可用.我也想保护这些，以便当用户取消发布页面时，他们可以相信它完全消失了.(对于法院命令删除内容等司法问题非常重要......类似的事情可能会发生).

However, the assets are still available. I want to protect those as well, so that when the user un-publishes a page, they can trust it is completely gone. (Very important on judicial troubles like court orders to take content down ... Things like that can happen).

最明显的方法是将所有资产存储在安全目录中(= Web 服务器无法访问)，并使用 PHP 前门"在检查后传递文件.当一个项目需要防水时，这是我目前采用的方式，但我不喜欢它，因为 PHP 解释器为网站上的每个小图像、脚本和样式表运行.我想要一个更快的方法.

The most obvious way is to store all assets in a secure directory (= not accessible by the web server), and use a PHP "front gate" that passes the files through after checking. When a project needs to be watertight this is the way I currently go, but I don't like it because the PHP interpreter runs for every tiny image, script, and stylesheet on the site. I would like have a faster way.

.htaccess 保护(拒绝所有人或类似)并不完美，因为 CMS 应该是可移植的并且能够在共享环境中运行.我希望它甚至可以在 IIS 和其他 Web 服务器上运行.

.htaccess protection (Deny from all or similar) is not perfect because the CMS is supposed to be portable and able to run in a shared environment. I would like it to even run on IIS and other web servers.

我现在能想到的最好方法是在未发布时将特定页面的资产目录移动到安全位置，并在发布时将其移回.但是，即使页面未发布，管理员用户也需要能够看到该页面，因此我必须解决我必须从安全目录提供这些资产的事实.

The best way I can think of right now is moving the particular page's asset directory to a secure location when it is un-published, and move it back when it's published. However, the admin user needs to be able to see the page even when it's un-published, so I would have to work around the fact that I have to serve those assets from the secure directory.

有人能想出一种方法，允许 Apache 直接访问文件(=不通过 PHP 脚本)但仍然使用 PHP 控制访问吗?我不能.

Can anybody think of a way that allows direct Apache access to the files (=no passing through a PHP script) but still controlling access using PHP? I can't.

我还会考虑一个简单的 .htaccess 解决方案，它可能在大多数共享环境中运行.

I would also consider a simple .htaccess solution that is likely to run on most shared environments.

推荐答案

管理界面的混合怎么样?在 ACP 中，您可以通过 PHP 方法访问，基本上，将所有文件请求发送到 PHP 身份验证文件，但对于公共，您可以使用 HTTP AUTH/htaccess 来确定结果的可用性.这为您提供了公共方面的性能，但在 ACP 方面提供了保护.

How about a hybrid for the administrative interface? In the ACP you could access via the PHP method to, basically, send all file requests to the PHP authing file, but for public, you can use HTTP AUTH/htaccess to determine the availability of the result. this gives you the performance on the public side, but the protection on the ACP side.

旧消息:

.htaccess 在使用 mod_rewrite 类型操作时与大多数 Apache 和 IIS<7 环境(使用各种 ISAPI 模块)兼容.唯一的例外是 IIS7 + 使用 web.config 文件的新 Rewrite 模块.但是，我愿意您可以有效地为此实例生成/更改 web.config 文件，而不是使用 .htaccess.

.htaccess is compatible with most Apache and IIS<7 environments (using various ISAPI modules) when using mod_rewrite type operations. The only exception is IIS7 + the new Rewrite module which uses the web.config file. HOWEVER, I'd be willing to be that you could efficiently generate/alter the web.config file for this instance instead of using .htaccess.

鉴于此，您可以使用重写方法设置重定向并重定向到您的自定义 404 页面(希望发送正确的 404 标头).这不是 100% 合适，因为实际资产应该是提供 403 标头的资产，但是......它有效.

Given that, you could set up redirects using the rewrite method and redirect to your custom 404 Page (that hopefully sends the proper 404 header). It is not 100% appropriate because the actual asset should be the one giving a 403 header, but... it works.

除非您想为每个服务器平台正确创建 HTTP AUTH 设置，否则这就是我要走的路线.另外，如果您做得对，您可以使您的系统可扩展，以允许您或您的用户将来使用其他类型(如果他们想这样做，包括基于 php 的选项).

This is the route I would go unless you want to properly create HTTP AUTH setups for every server platform. Plus, if you do it right, you could make your system extendable to allow other types in the future by you or your users (including a php based option if they wanted to do it).

这篇关于在 PHP 级别保护文件的面向性能的方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！