我尝试了http://myserver.com/~user=username&password=mypassword，但没有工作。
您可以确认实际上无法通过HTTP参数（GET或POST）传递用户/传递吗？
#1 楼
确实不可能通过标准HTTP身份验证中的查询参数传递用户名和密码。取而代之的是，您使用特殊的URL格式，例如：http://username:password@example.com/ －这将在标准HTTP“授权”标头中发送凭据。或查看查询参数并验证凭据的代码。这不是标准的HTTP身份验证，而是特定于应用程序的事情。评论
谢谢，这正是我一直在寻找的...它不是GET参数，只是可以将其制作为URL并不重要。
–ripper234
2012年3月21日在12:48
仅供参考，IE或Chrome不再支持http：// username：password@example.com格式，如果还没有其他人效仿的话，也不会感到惊讶。
– T.J.拥挤者
2014年6月20日10:31
在Chrome中实际上可以正常工作。只有IE被宠坏了。
–Damien Overeemツ
14年8月18日在13:12
@DamienOvereem您使用什么版本的chrome？我在Mac OS X 37上运行，似乎对我不起作用
–克里斯·达莫（Chris DaMour）
14年8月27日在16:23
从那以后，我了解到Chrome已禁用了一段时间，但后来又重新启用了此功能。我还了解到Safari进入这些类型的链接时会引发网络钓鱼错误。基本上，基于url的http身份验证的时间已经结束。
–Damien Overeemツ
2014年8月28日在9:20
#2 楼
http：// username：password@example.com适用于FireFox，Chrome，Safari BUT，不适用于IE。Microsoft知识库
评论
此功能已从Chrome 19+中删除。请参阅code.google.com/p/chromium/issues/detail?id=123150
– Moshe Katz
13年10月31日在21:07
通过阅读该错误报告，我将其重新添加到Chrome 20中。当然，如果不是这样，我希望看到很多人继续抱怨它。
–womble♦
2014年1月10日上午10:08
我现在为Internet Explorer请求它：connect.microsoft.com/IE/feedback/details/873575/…。用例略有不同，但是解决了相同的问题;）
–SimonSimCity
14年5月16日在13:03
如果密码包含“ @”，则@Diago无效。它会导致致命错误，任何人都可以告诉我如何立即提供用户名和密码
– Ashish Jain
15年3月4日在7:50
@AshishJain-我会尝试将密码中的@转义为％40。 （不过，我不知道这是否可行，并且可能取决于服务器或浏览器/服务器的组合。）
– David Moles
2015年4月14日0:00，
#3 楼
不建议在URL中传递基本身份验证参数为此有一个Authorization标头字段，请在此处检查：
http标头列表
如何使用它此处：
基本访问身份验证
您还可以看到，尽管某些浏览器仍支持它，但不建议在URL中添加基本授权凭证的建议解决方案。
另请参阅RFC 2617-HTTP身份验证中的第4.1章，以获取有关为什么不使用基本身份验证的更多详细信息。
在查询字符串中传递身份验证参数
使用OAuth或其他身份验证服务时，通常还可以通过查询字符串而不是授权标头发送访问令牌，例如：
GET https://www.example.com/api/v1/users/1?access_token=1234567890abcdefghijklmnopqrstuvwxyzABCD
评论
以及如何将Authorization标头编码为URL？
–womble♦
2014年1月10日上午10:09
您所说的表格不是现在已经过时了吗？
–womble♦
2014年1月14日下午4:37
您用“为此目的有一个授权标头字段”回答的问题是询问如何将身份验证参数放入URL。如果您不能将HTTP标头字段编码为URL（您不能这样做），那么您的答案是不合逻辑的。
–womble♦
2014年1月15日22:17
您能否列举URI标准中不赞成在URI中传递基本身份验证参数的地方？ RFC 2396只说“不推荐”，因为在许多情况下，纯文本身份验证详细信息不是一个好主意（我同意），而RFC 7235没有提及。在我可以搜索的规格中没有任何地方说它已被弃用。
– Lie Ryan
15年7月1日在13:21
@Wilt：我要道歉，你的确是正确的。您关于规范已“更改”的提示促使我进行进一步的研究（RFC一旦发布/编号，就永远不会被修改）。我只是发现RFC 2396实际上已被RFC 3986取代，而我之前找不到。 RFC 3986确实提到了username：password语法的弃用：不建议在userinfo字段中使用格式“ user：password”。
– Lie Ryan
2015年7月1日14:19
#4 楼
在您的示例中，URL http://myserver.com/将是：
http：// username：password@example.com/myserver.com/
截至2019年12月19日，我已经对此进行了测试，它适用于
Chrome
Firefox
Safari
，但不适用于不再支持的IE基本身份验证。
我使用SSRS 2017实现了此功能，该功能隐藏了用户名和密码。
我建议您使用隐身浏览器进行测试。在不同的隐身浏览器中使用和不使用密码进行测试。没有密码的人应该询问您密码。
评论
“ IE，它不再支持基本身份验证。” -您的意思是在URL的userinfo部分传递用户凭证。 IE仍支持“ [HTTP]基本身份验证”。您的示例URL应为：http：// username：password@myserver.com/。
–怀特先生
1月31日20:57
#5 楼
（显然）可以在GET参数中发送任何字符串，尽管不建议发送登录名和密码，因为这样做可以使其高度可见，特别是如果它不在AJAX请求中。但是，您将，然后需要对服务器页面进行编码以提取登录名和密码，然后以所需的任何方式进行验证和使用。
评论
用户：pass@example.com@sam-什么？完整的URL看起来如何？
全部符合规格ietf.org/rfc/rfc1738.txt（3.1）
@sam-抱歉，由于某种原因，我只是无法解析您的评论。