使用 PHP 或 HTML 更改 HTTP 请求授权标头

Posted 2023-03-21

【中文标题】使用 PHP 或 HTML 更改 HTTP 请求授权标头

【英文标题】：Change HTTP request authorisation header with PHP or HTML

【发布时间】：2016-06-03 21:45:48

【问题描述】：

快速问题是：有没有办法用 html / php / javascript 更改 http 授权标头？

目标

我想做一个用于用户登录以及提供整个站点保护的身份验证服务。除非获得授权，否则我希望限制用户查看除登录页面以外的任何文件。对于 php，我当然可以在开始时检查会话令牌的可用性，如果丢失则重定向，但对于 jpg 图像，我不能直接执行此操作。我想创建一个 htaccess 文件来验证用户是否已登录。

解决办法

1.

我使用 Apache 创建了 .htaccess 文件，用于验证是否设置了 HTTP 授权。如果不是，它重定向任何登录页面的请求。使用该解决方案，除了登录页面之外，无法打开任何文件（无论是 php 脚本还是例如 jpg 图像）：

RewriteCond %HTTP:Authorization ^$
RewriteCond %REQUEST_URI !^/login.php
RewriteRule .* /login.php [L,R]

2.

登录页面应显示表单，当登录名和密码正确时，使用正确的令牌设置 http 请求身份验证标头。

不幸的是，我找不到手动创建 http 请求身份验证标头的方法。我发现的唯一方法是使用基本身份验证：

$auth = new Auth();
if (!empty($_SERVER['PHP_AUTH_USER']) && !empty($_SESSION)) 
    $auth->logout();

if (!empty($_SERVER['PHP_AUTH_USER']) && empty($_SESSION)) 
    $login = $_SERVER['PHP_AUTH_USER'];
    $haslo = (!empty($_SERVER['PHP_AUTH_PW']) ? Auth::hashPassword($_SERVER['PHP_AUTH_PW']) : null);
    $auth->login($login, $haslo);

$auth->getLoginForm();

getLoginForm() 在哪里显示 Basic Auth 标准表单

public function getLoginForm()

    header(self::HEADER_ERROR_ASK_CLIENT_DATA);
    header(self::HEADER_RESPONSE_401);
    exit;

此解决方案有效，但 http 请求身份验证标头始终保存原始登录数据，这是我想要避免的。我想在那里注入“Bearer + token”字符串，这将有助于保护整个系统。

我试过的

我可以通过外部前端轻松做到这一点。例如，使用 Windows 桌面应用程序，我可以发送一个带有基本身份验证标头的请求，下一个带有承载标头的请求。

我可以用 JQuery 和 AJAX 做同样的事情 - 我可以使用带有基本身份验证的 url 检索令牌，然后使用带有自定义标头的令牌进行下一个请求。

我还可以使用 PHP CURL 发出不同的请求。

但我找不到强制常规浏览器使用基本身份验证标头登录并在成功后为下一个请求保留新的自定义承载标头的方法。

【参考方案1】：

没有标准机制可以让用户代理（浏览器）自己提供Authorization: Bearer 标头。

你可以做什么：

确保您的所有请求都通过 XHR (Ajax) 完成，并将标头发送到那里。但这将不允许“常规”文件加载（新页面、图像、脚本、CSS...）。

大多数人的做法是：发送一个带有您的身份验证令牌的 cookie，然后检查该 cookie。浏览器会自动发送cookie。

顺便说一句，请注意您的 .htaccess 仅检查是否存在 Authorization 标头，而不是其值，因此它毫无用处。您希望通过一个脚本来引导所有读取，该脚本将在交付文件之前实际验证标头或 cookie。

【讨论】：

标头名称是Authorization，而不是Authorisation。

@Pemapmodder 确实错过了自动更正（使用英国词典）。修复。

你确实是对的 - 当前形式的 htaccess 是没用的。我尝试使用 auth_external 将它与 PHP 一起使用，但我的 ISP 不允许这样做。我的最后一个想法是只保留它作为对普通用户的小保护。虽然简单的login:[e-mail] 会绕过它。我想我坚持你的建议 - 只保护脚本文件或通过脚本路由所有文件。然而，这最后一个选项看起来并不是最好的主意。

这显然不如让 Web 服务器直接传递静态文件效率低，但只要进行最低限度的优化（包括使用 readfile），它应该不会成为太大的问题。

好吧，我会坚持那个解决方案。谢谢！