背景
(如果您熟悉CORS,最后可以跳到问题)
CORS [1]是一种允许浏览器允许访问来自不同域的资源的解决方案.例如,使用AJAX的REST数据后端.
在互联网上很好地观察到Chrome(和Webkit好友)在这样的资源需要时不处理HTTP身份验证提示.例如[2](这是为了防止浏览器显示auth登录对话框,例如,当图像标签加载失败并且需要凭据时,Web-Mail登录页面.用户可能被欺骗进入他们的网络邮件凭据)
Chrome在这种情况下的行为是放弃响应,几乎无声地取消请求.
事实上,如果发生200,Chrome只会正常通过响应; 吞下任何其他状态代码并中止AJAX调用.
如果使用jQuery执行Ajax请求,并且远程站点使用HTTP 401状态代码进行响应,则取消请求并且ajax完成并出现错误,但缺少401代码.好像连接死了或等同的下层问题.
我见过的唯一一个提到CORS这个警告的网站是[1]
浏览器在报告错误时没有很好地报告出错的地方.例如,Firefox报告所有错误的状态为0和空状态文本.浏览器还会向控制台日志报告错误消息,但无法从JavaScript访问此消息.处理错误时,您将知道发生了错误,但没有其他错误.
您可以通过使用chrome启动标志来禁用此安全性 - 只是为了测试后端是否正常运行,并且一个健全状态不会因丢失正确的状态代码而受到不适当的影响.见[2]
问题
如果后端和前端客户端代码应该使用401作为其身份验证过程的一部分,该怎么办？ - 任何失败只会被误导成一个"错误"输出.
例如:在发出身份验证请求时 - 例如,双腿OAuth令牌请求 - 对使用正确状态代码的RESTful后端 - 客户端不知道是否:
我们的后端写得相当 RESTful,遵循当时认为具有成本效益的最佳实践; 其中一个依赖于正确的HTTP状态代码.我们反对的Java REST客户端运行良好.
现在我已经开始创建一个Javascript客户端,用于嵌入网页 - 特别是使用CORS,我们已经解决了Chrome等问题.(注意Firefox 似乎很好,我们目前通常不关心IE.)
题
人们为解决这些问题做了什么？
有什么办法可以使CORS更适合可信赖的后端吗？
链接