AJAX/oData 身份验证的 HTTP 响应和标头？
当身份验证 cookie 过期且需要更新时，oData 或 AJAX 服务应如何响应？
时，服务器应向客户端发送什么
- 当
禁止 oData 或 AJAX 服务访问（访问被拒绝）
当会话凭据过时时，并且需要更新，可能通过重定向到 ADFS、OpenID 或 Azure ACS IDP
只要查看维基百科，我就猜测我应该为第一个场景发送某个版本的 403.x，为第二个场景发送 401。
请确认上述内容是否正确，以及我应该在响应标头和正文中包含哪些内容。
我认为不正确的一些示例执行以下操作：
- 以静默方式使 AJAX 服务出错并且不返回任何数据
- 尝试将 AJAX 调用重定向到 IDP
- 将非 JSON 格式的错误文本发送到客户端
How oData or AJAX services should respond when the authentication cookie is expired and it's time to renew?
What should the server send to the client when
An oData or AJAX service access is forbidden (access denied)
When the session credentials are stale, and need to be renewed, perhaps by redirecting to an ADFS, OpenID, or Azure ACS IDP
Just looking in Wikipedia lets me guess that I should send some version of 403.x for the first scenario, and a 401 for the second scenario.
Please confirm if the above is correct, and what I should include in the response header and body as well.
Some examples I assume to be incorrect do the following:
- Silently error out the AJAX service and return no data
- Attempt to redirect the AJAX call to the IDP
- Send error text to the client that is not in JSON format
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 HTTP 状态代码总是安全的，而不是编写自己的令牌或类似的东西。
由于 OData 的基本原理是让任何知道如何进行 HTTP 通信的客户端都可以使用，因此使用 HTTP 状态代码是有意义的。客户将决定对特定状态代码执行什么操作。
its always safe to play with the HTTP Status codes instead of cooking up your own tokens or anything of that sort.
Since the fundamentals of OData is to make it possible for any client which knows how to communicate HTTP, it makes sense to play around the HTTP status code. The clients will decide what to do on a particular status code.
HTTP 状态代码是最佳选择。 OData 特别不定义任何已在较低级别实现的内容（例如安全性和身份验证）。401
表示未经身份验证，403 表示未经授权。对于场景 1，您只说“访问被拒绝”，但没有说您拒绝访问的原因。用户未经过身份验证吗？然后返回401。用户是否已通过身份验证但缺乏权限？然后返回 403。
对于场景 2，我同意返回详细的 401 状态（即为您的身份验证提供程序提供有效的“WWW-Authenticate”标头。）
我建议从以下位置开始的 Wikipedia 文章（您可能已经找到了）是：https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_status_codes
希望这对某人有帮助。 :-)
HTTP Status Codes are the way to go. OData specifically doesn't define anything that is already implemented at a lower level (such as security and authentication.)
401 is for Unauthenticated, 403 is for Unauthorized. For secnario 1 you only say "Access denied" but not why you're denying access. Is the user not authenticated? Then return 401. Is the user authenticated but lacking privileges? Then return 403.
For scenario 2, I would agree, return a detailed 401 status (i.e. with a valid "WWW-Authenticate" header for your authentication provider.)
The Wikipedia article I recommend starting at (you may have already found this) is: https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_status_codes
Hope this helps someone. :-)