如何在 RESTful 系统中通过 HTTP GET 请求传递授权数据？
这可能是最基本的问题，出于某种原因，但我有点目瞪口呆。我正在设计一个有多个页面的宁静服务。默认情况下单击链接会触发 HTTP GET
现在如何通过 get 请求发送授权数据？它应该是网址的一部分吗？我将被迫创建一个带有加密查询参数的丑陋网址。有什么办法可以避免这种情况吗？
可以这么说，javascript/jquery 中是否有某些东西可以“在幕后”发送这些数据？
在 JQuery 中，$.ajax 方法将用户名、密码 作为参数，以便授权数据可以与 ajax 调用一起发送。对于非 ajax 调用有什么等价的东西，还是我只留下 URL？
采用这种方法的原因：
- 我希望用户能够单击“后退按钮”并返回到上一页。如果我使用授权执行
$.get，然后使用$('html').replaceWith(result)，它将禁用后退按钮，对吗？ （即，不显示任何内容）
这可能应该是 REST 101，但由于某种原因，它让我陷入困境
（仅供参考：技术：Jquery/javascript/Restlet/Freemarker）
（PS：Cookies 作为最后的手段。或者它们是最好的方法？ :)
This is probably the MOST basic question and for some reason but I'm a bit dumbfounded. I am designing a restful service which has multiple pages. Clicking on a link by default fires an HTTP GET
Now how do I send authorization data with the get request? Should it be part of url? I'll be forced to create an ugly url with encrypted query parameters. Is there any way to avoid this?
Is there something in javascript/jquery that could just send this data 'under the hood', so to speak?
in JQuery the $.ajax method takes username, password as arguments so that authorization data can be sent along with the ajax call. Anything equivalent for non-ajax calls or am I left with the URL only?
Reason for this approach:
- I want the user to be able to click the 'back button' and go back to the previous page. If I did a
$.getwith the authorization, and followed it with$('html').replaceWith(result)it would disable the back button, correct? (i.e., not show anything)
This should probably be a REST 101 but for some reason it's had me cornered
(FYI: Technologies: Jquery/javascript/Restlet/Freemarker)
(PS: Cookies as last resort. Or are they the best way? :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于 GET 请求，您只能使用请求标头和请求的查询字符串/URL。您可以使用 HMAC 方法或 OAUTH，其中每个请求都经过“签名”。如果您纯粹在客户端进行此操作，则存在共享秘密不再是秘密的问题。
当然，听起来您已经在使用用户名和密码发出 POST 请求（顺便说一句，我强烈建议您这样做）
如果您想要 HMAC 的实际示例，我相信 Amazon 确实（或曾经）使用 HMAC 与 S3 进行交互，所以周围有很多示例代码。
最终，在不泄露一些“秘密”信息（例如密码或私钥/令牌）的情况下，让 Web 客户端进行无状态身份验证是非常困难的。您可以向用户颁发临时令牌，然后通过验证请求标头（IP 地址等）在令牌生命周期内是否一致来进行备份。如果您要向客户端公开临时令牌，您可能希望您的身份验证机制包含一个唯一的 nonce< /a> 也按请求。
如果您希望 Web 客户端执行请求，那么纯粹的无状态 RESTful 身份验证就很重要，所以我不会将其称为 REST 101 :)
With GET requests, you are limited to the Request headers and the query string/url of your request. You can use an HMAC approach or OAUTH, where each request is 'signed'. If you are doing this purely client side, there is the problem of the shared-secret no longer being, well, secret.
Of course, it sounds like you are already making POST requests using the username and password (which I highly discourage, BTW)
If you're wanting examples of HMAC in action, I believe Amazon does (or did) use HMAC for interacting with S3, so there are a lot of sample code around.
Ultimately, it is very difficult to have the web-client do stateless authentication without disclosing some 'secret' information, such as passwords or private keys/tokens. You could issue temporary tokens to the user that are then backed up by validating that the request headers (IP address, etc) are consistent through the life of the token. If you're disclosing temporary tokens to the client, you'll probably want your authentication mechanism to include a unique nonce per request, as well.
Purely stateless RESTful authentication is non-trivial if you want the web-client to be doing the requests, so I wouldn't call it REST 101 :)