Web应用程序的RESTful身份验证

嗨已经写了这个观察和问题,关于这个问题的较早,但后来才发现,这是一个老"死"的问题.由于我非常喜欢其他人的一些见解,我将其作为一个新问题重新发布.

对于如何进行RESTful身份验证的问题,人们通常会热情地喊出"HTTP身份验证".但是,我怀疑这些人是否曾尝试使用REST 制作基于浏览器的应用程序(而不是机器到机器的Web服务).(没有违法行为 - 我只是认为他们没有遇到过并发症)

我在RESTful服务上使用HTTP身份验证发现的问题是生成可在浏览器中查看的HTML页面:

用户通常会得到一个丑陋的浏览器制作的登录框,这对用户不友好.你不能添加密码检索,帮助框等.

以不同的名称注销或登录是一个问题 - 浏览器将继续向站点发送身份验证信息,直到您关闭窗口

超时很难

铲球这些逐点非常有见地的文章是在这里,但是这导致的很多特定浏览器的JavaScript两轮牛车,变通办法变通办法,等等的.因此,它也不是向前兼容的,因此在发布新浏览器时需要不断维护.我不认为干净清晰的设计,而且我觉得这是一项额外的工作和头痛,这样我就可以热情地向我的朋友展示我的REST徽章.

我相信cookie是解决方案.但等等,饼干是邪恶的,不是吗？不,他们不是,饼干的使用方式往往是邪恶的.Cookie本身只是一条客户端信息,就像浏览器在浏览时会跟踪的HTTP身份验证信息一样.这条客户端信息在每次请求时都会发送到服务器,就像HTTP身份验证信息一样.在概念上,唯一的区别是所述内容这块客户端状态中的可以由确定服务器作为其响应的一部分.

通过使用以下规则使会话成为RESTful资源:

一个会话映射一个关键用户ID(也可能是最后行动时间戳超时)

如果存在会话,则表示该密钥有效.

登录意味着POST到/ sessions,新密钥被设置为cookie

注销意味着DELETEing/sessions/{key}(重载POST,请记住,我们是浏览器,HTML 5还有很长的路要走)

通过在每个请求时将密钥作为cookie发送并检查会话是否存在且有效来完成身份验证

现在,与HTTP身份验证的唯一区别在于,身份验证密钥由服务器生成并发送给不断发送回来的客户端,而不是客户端从输入的凭据计算它.

我认为这是一个运行良好的充分解决方案,但我必须承认,我不足以识别此方案中的潜在漏洞 - 我所知道的是,数百个非RESTful Web应用程序使用的基本相同登录协议($ _SESSION inphp,j2ee中的HttpSession等).cookie头内容仅用于寻址服务器端资源,就像接受语言可能用于访问翻译资源一样,等等.我觉得它是一样的,但也许其他人不一样？你们觉得怎么样？