在HTTP Basic Auth的URL中传递用户名和密码 [英] Pass username and password in URL for HTTP Basic Auth

问题描述

传递URL中编码的用户名和密码时，例如：
https： //Aladdin:[e-mail]/index.html

When passing username and password encoded in URL, eg: https://Aladdin:[e-mail]/index.html

客户端实际上是在Authorization标头中发送了吗？
这种URL编码在服务器端需要什么样的处理？

Is the client in fact sending this in Authorization header? What kind of processing is needed on server side for this kind of URL encoding?

推荐答案

是客户实际上是通过授权标题发送的吗？

这取决于客户端是什么。如果客户端是浏览器，答案是否定的。以下是实验结果：

It depends on what the client is. If the client is a browser, the answer is no. Here is the experiment result:

• 在Chrome中，未发送任何授权标头。


• 在Firefox中，没有发送授权标头。 Firefox也会提示确认对话框，因为主动发送身份验证信息很奇怪。


• 在Safari中，不会发送授权标头。 Safari首先会显示一个警告页面，因为它怀疑该URL属于一个钓鱼网站。


• 在Opera中，没有发送授权标题。


• 我在Mac上，无法在IE / Edge上运行实验。但根据其他浏览器的合理行为，我猜IE / Edge的行为是一样的。无论如何，如果有人参加实验并获得结果，我将不胜感激。

• In Chrome, no authorization header is sent.
• In Firefox, no authorization header is sent. Firefox will also prompt a confirm dialog, as proactively sending authenticate information is weird.
• In Safari, no authorization header is sent. Safari will also display a warning page first, as it suspect the URL is belong to a fishing site.
• In Opera, no authorization header is sent.
• I'm on Mac and can't run experiment on IE/Edge. But according to other browser's behaviour which is reasonable, I guess IE/Edge would act the same. Anyway, I'd appreciate if someone takes an experiment and get the result.

一般来说，浏览器会忽略主动发送的身份验证信息URL，出于安全原因。

Generally speaking, browser will ignore authenticate information proactively sent in URL, for security reason.

但是，如果客户端是开发工具，则可以在base64中对身份验证信息进行编码，并将其作为授权标头发送。以下是一些实验结果：

However, if the client is a development tool, the authenticate information may be encoded in base64 and sent as Authorization header. Here is some experiment result:

• 在卷曲中，是的，会发送授权标题。


• 在邮递员中，没有发送授权标题。

是否发送授权标头取决于工具的设计。

Whether the authorization header is sent depends on the tool's design.

这种URL编码在服务器端需要什么样的处理？

在服务器端，您需要做的就是从Authorization标头获取base64编码的字符串，对其进行解码，并检查它是否有效。

In server side, all you need to do is get the base64 encoded string from Authorization header, decode it, and check whether it is valid.

如果有任何不同， HTTP协议在示例URL中使用？

为了安全起见，是的，通过HTTP的授权标头非常不安全。 Base64编码/解码不会带来任何安全性好处，可以被所有人解码。

For security, yes, Authorization header through HTTP is very insecure. Base64 encoding/decoding will not make any security benefit, it can be decoded by everyone.

否则，它们是相同的。

这篇关于在HTTP Basic Auth的URL中传递用户名和密码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！