通过 SSL 和 HTTP 基本身份验证的 REST 服务
在 保护 API：SSL 和HTTP 基本身份验证与签名 HTTP 基本身份验证被认为是保护 REST Web 服务调用（如果通过 SSL 进行 REST 调用）的充分方法。
但似乎此方法仍然不适用于使用 Ajax 调用受 SSL 和 SSL 保护的 REST 服务的不安全客户端页面。基本认证
我正在尝试设计一个使用通常方式执行密码重置的应用程序：
- 用户输入用户名并请求“重置密码”电子邮件
- 用户收到带有密码重置链接的电子邮件，其中包含可验证的令牌
- 用户单击该链接并且（在令牌被删除之后） 根据定义
，这些页面不需要需要登录。这个 UI 可以使用 Ajax 来实现，调用 REST 服务来执行验证令牌、发送电子邮件等操作吗？即使这些 REST 服务受到 SSL 和 SSL 的保护。基本身份验证，您调用服务所需的信息（即应用程序的“用户名”和密码）最多将保存在可通过浏览器访问的 cookie 中。
我知道我错过了一些东西。我只是不知道什么:-)
In Securing an API: SSL & HTTP Basic Authentication vs Signature HTTP Basic Authentication is cited as an adequate way to secure REST web service calls if the REST calls are made through SSL.
But it seems this method will still not work for an unsecured client page that uses Ajax to make calls to the REST service that is protected behind SSL & Basic Auth.
I am trying to design an application that performs password reset using the usual way:
- user enters username and requests "reset password" email
- user receives email with a password reset link that includes a verifiable token
- user clicks on the link and (after the token is verified) types in their updated password
By definition these pages do not require login. Can this UI be implemented using Ajax that calls REST services to do things like validate token, send email, etc.? Even if those REST services are protected behind SSL & Basic Auth, the information that you need to call the service (i.e. the application's "username" and password) will be at best in cookies which would be accessible through the browser.
I know I am missing something. I just don't know what :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只要 SSL 下发生 1 - 3 步，数据就可以安全地通过线路传输到服务器（假设您信任证书颁发机构）。
在此过程中，浏览器会将这些凭据保存在内存中。如果用户要输入数据，您别无选择，只能相信这一点。
网站代码决定是否在 cookie 中存储信息。
我认为如果 1 - 3 个都在 SSL 下，你应该没问题。
As long as 1 - 3 happen under SSL, the data will be safe over the wire to the server (assuming you trust the certificate authority)
During that process, the browser will hold those credentials in memory. You have no choice but to trust that if the user is going to enter the data.
It is the web sites code that determines whether to store info in cookies.
I think you should be OK if 1 - 3 are under SSL.
我不知道你在保护什么，所以我只是抛出一些想法。
如果您（或其他不感兴趣的人）无法控制依赖方的根列表，则 SSL 和 TLS 就没有意义。我这样说是因为我希望如果你不信任拥有锁钥匙的人，那么你就不会把钱存入他的金库。因此，如果加载登录页面的用户在野外，那么用户/通过 TLS 的门槛就很低，对于保护我最喜欢的电影列表来说绝对足够了。
卡比赞扬所有的FSM
I've no idea what you're protecting so I'l just toss some thoughts out.
SSL and TLS are not meaningful if you (or someone else who gives a hoot) aren't in control of the root list of the relying party. I say this because I expect that if you don't trust the guy with the key to the lock then you won't put your money in his vault. So if the users loading the login pages are in the wild so to speak then user/pass through TLS is a low bar, definitely good enough for protecting my favorite movies list.
Carby praises to the all being FSM