我目前正在开发一个 REST-API,它为开发环境提供 HTTP-Basic 保护。由于真正的身份验证是通过令牌完成的,我仍在尝试弄清楚如何发送两个授权标头。
我试过这个:
curl -i http://dev.myapp.com/api/users \
-H "Authorization: Basic Ym9zY236Ym9zY28=" \
-H "Authorization: Bearer mytoken123"
例如,我可以禁用我的 IP 的 HTTP 身份验证,但由于我通常在具有动态 IP 的不同环境中工作,这不是一个好的解决方案。那我是不是错过了什么?
尝试使用此方法在 url 上推送基本身份验证:
curl -i http://username:[email protected]/api/users -H "Authorization: Bearer mytoken123"
^^^^^^^^^^^^^^^^^^
如果以上方法不起作用,那么与您无关。因此,请尝试以下替代方案。
您可以使用其他名称传递令牌。因为您正在处理来自您的应用程序的授权。因此,您可以轻松地将这种灵活性用于此特殊目的。
curl -i http://dev.myapp.com/api/users \
-H "Authorization: Basic Ym9zY236Ym9zY28=" \
-H "Application-Authorization: mytoken123"
请注意,我已将标题更改为
Application-Authorization
。因此,从您的应用程序中捕获该标头下的令牌并处理您需要执行的操作。
您可以做的另一件事是,通过
token
参数传递 POST
并从服务器端获取参数的值。例如使用curl post参数传递令牌:
-d "auth-token=mytoken123"
标准(https://www.rfc-editor.org/rfc/rfc6750)表示您可以使用:
因此可以通过 URI 传递许多承载令牌,但不鼓励这样做(请参阅标准中的第 5 节)。
如果您在中间使用反向代理(例如 nginx),您可以定义自定义令牌,例如
X-API-Token
。
在 nginx 中,您可以重写它以使上游代理(您的其余 api)只是身份验证:
proxy_set_header Authorization $http_x_api_token;
...而 nginx 可以使用原始的 Authorization header 来检查 HTTP AUth。
使用 nginx,您可以像这样发送两个令牌(即使它违反标准):
Authorization: Basic basic-token,Bearer bearer-token
只要基本令牌在前,此操作就有效 - nginx 成功将其转发到应用程序服务器。
然后您需要确保您的应用程序可以正确地从上面的字符串中提取承载。
我遇到了类似的问题 - 在设备上验证设备和用户。我在
Cookie
标题旁边使用了 Authorization: Bearer...
标题。一个标头对设备进行身份验证,另一个标头对用户进行身份验证。我使用了 Cookie
标头,因为它们通常用于身份验证。
curl——anyauth
告诉curl自己找出身份验证方法,并使用 远程站点声称支持的最安全的一种。这是由 首先执行请求并检查响应标头,因此 可能会导致额外的网络往返。这是用的 而不是设置特定的身份验证方法,您可以 使用 --basic、--digest、--ntlm 和 --谈判。
还有另一种在开发服务器上测试 API 的解决方案。
HTTP Basic Authentication
nginx
和Laravel
的Web服务器配置如下:
location /api {
try_files $uri $uri/ /index.php?$query_string;
}
location / {
try_files $uri $uri/ /index.php?$query_string;
auth_basic "Enter password";
auth_basic_user_file /path/to/.htpasswd;
}
Authorization: Bearer
将负责保护开发服务器免受网络爬虫和其他不需要的访问者的侵害。
您可以使用带有 x-www-form-url-encoded 的 Body 来发送多个标头。
curl --location --request POST 'http://dev.myapp.com/api/users' \
--header 'Authorization: Basic Ym9zY236Ym9zY28=' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'access_token=mytoken123'
真正的答案是
Bearer
令牌是一种授权方案,而Basic
是一种认证方案。因此,您的问题一开始就存在错误,并且您的应用程序逻辑流程存在问题。
您不知道,而且通常可能不知道客户端的用户名/密码和不记名令牌。在最常见的工作流程中,您执行一次身份验证,接收不记名令牌并在所有后续请求中使用它。此外,令牌可能有一个过期时间,作为基本礼貌,应用程序应在每个响应中指出该过期时间。
用最简单的术语来说,不记名令牌授权是旧的、可信赖的会话 cookie 的特例。