如何防止 Safari 拦截 ajax 请求的 401 响应
我在 Safari 扩展中遇到以下问题。我要求用户提供 Web 服务的用户名/密码，并发送一个快速请求以验证凭据是否正确。如果不是，该服务将响应 401，我认为它应该如此。问题是 Safari 似乎在我的 javascript 代码可以处理它之前拦截了这个响应，显示灰色登录框而不是让我处理错误。
我能做些什么吗？我使用 js 库来进行调用，但它在功能上等同于以下 jQuery。
$.ajax({
type: "GET",
url: url,
username: username,
password: password,
success: function() { /* handle success */ },
error: function() { /* handle error */ }
});
I'm having the following problem in a Safari extension. I ask the user to provide their username/password for a web service and send off a quick request to verify that the credentials are correct. If they are not, the service will respond with a 401 as I believe it should. The problem is that Safari seems to intercept this response before my javascript code can handle it, showing the grey login box instead of letting me handle the error.
Is there anything I can do about this? I'm using a js library to make the call, but it's functionally equivalent to the following jQuery.
$.ajax({
type: "GET",
url: url,
username: username,
password: password,
success: function() { /* handle success */ },
error: function() { /* handle error */ }
});
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知（在我自己遇到这个问题之后），您无法让 Safari 停止拦截
401。如果这些发现是正确的，唯一的方法是创造性地（阅读：错误）使用另一个错误代码，例如403，或使用自定义代码（见下文）。当然，这假设您有权更改从 Web 服务发回的状态代码（如果您也开发了 Web 服务，则问题并不完全清楚）。
当然，
403实际上是说“您已经通过身份验证，但无权访问此资源”，这是不正确的（因此是“滥用”），但至少它没有副作用在我所知道的浏览器中。400有时被用作替代方案，但由于该错误（“错误请求”）实际上意味着 HTTP 协议错误，因此它可能会导致副作用（从未见过或听说过它发生，但潜在地，它可能会导致某些未来的浏览器或反劫持软件开始进行故障排除/诊断的过度尝试）。412是我见过的另一种替代方案（“先决条件失败”），但它实际上意味着服务器没有达到先决条件请求设置。或者您可以编写自己的非标准
4xx错误 - 例如461- 这是允许的（请注意，twitter 有一个自定义的420状态代码， 例如）As far as I'm aware (after having had this issue myself) there's no way you'll get Safari to stop intercepting a
401. If those findings are correct, the only way is creative (read: mis-) use of another error code, e.g.403, or using a custom one (see below).Of course, this assumes that you have access to changing the status code sent back from the web service (it's not entirely clear from the question if you developed the web service too).
403, of course, really says "you're already authenticated, but not authorized to access this resource", which isn't correct (hence "misuse"), but at least it has no side effects in browsers that I'm aware of.400is sometimes used as an alternative, but since that one ("bad request") is really meant to signify a HTTP protocol error, it may cause side effects (never seen or heard of it happening, but potentially, it might cause an over-helpful attempt by some future browser or anti-hijacking software to start troubleshooting/diagnostics).412is another alternative that I've seen used ("precondition failed"), but it actually is meant to indicate that the server didn't live up to the preconditions the request set.Or you could make up your own non-standard
4xxerror - e.g.461- which is allowed (notice that twitter has a custom420status code, for example)更正确的方法是继续使用
401作为错误代码，但在凭据已发送但不正确时不发送WWW-Authenticate标头。这不再触发浏览器的对话框并允许您直接处理
401。A more correct approach would be to continue to use
401as the error code but not send theWWW-Authenticateheader when the credentials have been sent but they were not correct.That no longer triggers the browser's dialog and allows you to process
401directly.