【问题标题】:Returning HTTP 401 status for AJAX responses without WWW-Authenticate为没有 WWW-Authenticate 的 AJAX 响应返回 HTTP 401 状态
【发布时间】:2014-10-05 20:24:59
【问题描述】:

如果您希望传达用户未登录的信息,是否可以返回 HTTP 401 状态以响应 AJAX 调用,即使登录机制是基于表单的而不是基于表单的基于 HTTP(基本、摘要等)?

这里的答案建议应该使用 401: https://stackoverflow.com/a/6937030/2891365

这篇文章展示了一个使用 401 进行 AJAX 响应的实际示例:http://www.bennadel.com/blog/2228-some-thoughts-on-handling-401-unauthorized-errors-with-jquery.htm

但是,RFC 2616 for HTTP/1.1 明确指出需要一个特殊的标头,暗示它只能用于 HTTP 身份验证。

10.4.2 401 未经授权

请求需要用户身份验证。响应必须包含一个 WWW-Authenticate 标头字段(第 14.47 节),其中包含适用于所请求资源的质询。

我想我可能可以发送像 WWW-Authenticate: WebForm 这样的虚假标头,并且仍然符合 W3C 规范,但感觉它违反了 WWW-Authenticate 标头的精神。

最后,我似乎找不到明确说明 HTTP 401 是否允许用于 AJAX 响应的权威来源。有没有我错过的权威来源?

【问题讨论】:

    标签: ajax http authentication http-response-codes www-authenticate


    【解决方案1】:

    我会说这不行,因为 401 是为了告诉客户端提供 http 身份验证凭据。正确的响应是 403 Forbidden,只是告诉客户端无论出于何种原因都不允许访问该资源。

    【讨论】:

    • 我正在这样做,但我意识到我需要一种方法来区分未经身份验证的请求和经过身份验证但无权限的请求。可以使用响应内容,但对于这样的事情有一个状态代码似乎更合乎逻辑。我希望有一个权威来源来指定如何最好地处理这种情况。
    • 除了 HTTP 认证之外的所有形式的认证或授权都超出了 HTTP 协议的范围。因此,虽然使用 cookie 或其他方式实现自定义安全机制是一种常见做法,但没有更具体地处理此类自定义实现的 HTTP 响应代码。 403仅表示“禁止”,没有给出任何具体原因。因此,与 HTTP 不关心的任何自定义安全机制相关的任何信息都应在响应正文中发送。
    • 我很想在这个用例中也使用 401,但鉴于 Mikael 的回答,我决定坚持使用 403。但是,我决定使用自定义 HTTP 标头而不是使用响应正文:X-Reason: LoginRequired。不确定这是否适合您的模特@Mikael?
    猜你喜欢
    • 1970-01-01
    • 2013-07-15
    • 1970-01-01
    • 1970-01-01
    • 2023-03-24
    • 2018-07-02
    • 2010-12-17
    • 2019-12-12
    • 1970-01-01
    相关资源
    最近更新 更多