如何正确加载和 HTML 嵌入受密码保护的文件?

发布于 2024-09-18 18:57:33 字数 909 浏览 2 评论 0原文

我有一个受 Apache 密码保护的目录,其中包含文本文件和电影文件。目前,我使用 cURL 加载文本文件的内容,并使用 CURLOPT_USERPWD 传递用户名密码信息。对于电影,我将 OBJECT 和 EMBED src 设置为 http://username: [电子邮件受保护]/file.mov。在这两种情况下,用户名密码都是从$_SERVER['PHP_AUTH_USER']$_SERVER['PHP_AUTH_PW']中提取的分别。如果这不起作用,则会提示用户通过通用 HTTP 身份验证弹出窗口提供新凭据。

有更合适的方法来做到这一点吗?或者嵌入受密码保护的电影只是一个错误/坏主意?

上述方法会导致两个(相关的?)问题。首先,(据我所知)随机地,嵌入电影时似乎没有传递用户名:密码@部分,因此用户被迫再次输入其凭据。这种情况很少发生,而且很烦人,但解决起来会很好。

其次,这会导致 Snow Leopard 下的 Safari 崩溃。 Safari 毫无疑问会提示用户输入凭据,然后冻结。不受密码保护的电影(或将受密码保护的电影移动到不受密码保护的目录)可以正常加载。这个问题在 Snow Leopard 之前并不存在,但我还没有在 Snow Leopard 下的旧版本 Safari 上测试过它,所以它可能是最近的更新之一打破了它。

注意: 遗憾的是,由于使用这些文件的其他程序需要 Apache 密码保护,因此无法迁移到另一个登录系统(从而消除该问题)。

I have an Apache password-protected directory filled with text files and movie files. Currently, I load the contents of the text files using cURL, passing the username and password information with CURLOPT_USERPWD. For the movies, I set the OBJECT and EMBED src's to http://username:[email protected]/file.mov. In both cases, the username and password are pulled from $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'], respectively. If that does not work, then the user is prompted to provide new credentials with a generic HTTP auth pop-up.

Is there a more proper way to do this? Or is embedding password-protected movies just a buggy/bad idea?

The above method results in two (related?) problems. First, (as far I can tell) randomly, it seems that the username:password@ part is not passed when embedding the movie, and thus the user is forced to enter their credentials again. This rarely occurs, and is only annoying, but would be nice to fix.

Second, this causes Safari under Snow Leopard to crash. Safari, without fail, prompts the user for credentials, then freezes. Non-password-protected movies (or moving the password-protected movies to a non-password-protected directory) load fine. This problem did not exist pre-Snow Leopard, but I haven't tested it on older versions of Safari under Snow Leopard, so it could be one of the recent updates broke it.

NOTE: Moving to another login system (thus negating the issue) sadly is not possible since other programs that use the files require Apache password protection.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

手心的海 2024-09-25 18:57:37

您的连接是否安全?否则看起来好像用户名/密码容易被窥探?

我倾向于使用服务器端脚本(例如 serve_content.php)来管理受保护内容的服务。并链接到它,如下所示:

src="serve_content.php?id=1234"

serve_content.php 检查用户是否已登录。根据传递的 id 识别文件(它掩盖了受保护内容的真实位置),因此“1234”可能是“我的电影.avi”。并将文件发送给客户端。例如。使用 readfile() 以及适当的标头。

Apache 受密码保护的目录可防止未经授权的直接访问。如果您通过其他方法登录用户,则任何用户都无法直接访问该文件,只能通过 serve_content.php 访问。

Are you on a secure connection? Otherwise it looks as if the username/password are open to prying eyes?

I would tend towards having a server side script (eg. serve_content.php) that manages the serving of your protected content. And link to it something like:

src="serve_content.php?id=1234"

serve_content.php checks that the user is logged in. Identifies the file from the passed id (which masks the true location of the protected content), so '1234' might be 'mymovie.avi'. And sends the file to the client. eg. using readfile() with the appropriate headers.

The Apache password-protected directory acts to prevent unauthorised direct access. If you were logging your users in by some other method, then no user would be able to access the file directly, only via serve_content.php.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文