http - 登录和重定向 : What is the best HTTP flow for a webapp login?

Question

这个问题是关于一般网络应用程序登录流程的问题。我对在保持安全性的同时优化可用性和性能的答案最感兴趣。

处理未经身份验证的对已添加书签的 URL 的请求的最合适方法是什么？

为了演示这个问题，下面是示例应用程序的一些路由和各自的行为:

GET /login         -> Display the authentication form
POST /processLogin -> process the username and password, 
                            if unauthentic...re-render the login form; 
                            otherwise...display the default page
GET /secret         -> if authenticated...display the secret resource;
                       otherwise...display a login form
POST /secret        -> if authenticated...perform a desirable, but potentially 
                                          non-idempotent action on the secret 
                                          resource
                       otherwise...display a login form

选项 1:显示登录屏幕，重定向到所需页面

1. 用户点击书签
2. GET/secret -> 200，暗中显示带有隐藏字段 path="/secret"的登录表单
3. POST/processLogin -> 302 到/secret(路径参数的值)
4. GET/secret -> 200，显示 secret 资源

分析:希望您的客户端是一个不符合 HTTP 的现代浏览器，以便它在 302's POST 之后执行 GET。这适用于所有领域。我应该担心吗？

选项 2:重定向到登录屏幕，重定向到所需页面

1. 用户点击书签
2. GET/secret -> 302 到/login
3. GET/login via redirect -> 200，登录表单显示隐藏字段 path="/secret"
4. POST/processLogin -> 302 到/secret
5. GET/secret -> 200，显示 secret 资源

分析:同上问题。增加了登录时浏览器显示的URL发生变化，使用户感到困惑并破坏书签、链接共享等的问题。

选项 3:显示登录屏幕，显示所需页面

1. 用户点击书签
2. GET/secret -> 200，用action="/secret"偷偷显示登录表单
3. POST/secret -> 200，显示 secret 资源

分析:可悲的是，刷新按钮现在也坏了:刷新将导致用户代理重新 POST 并发出警告，而不是重新获取/secret。他们的用户会收到警告，但如果他们忽略它，就会发生不好的事情。

好的一面是，您可以使用这种技术最大限度地减少往返。

选项 4:重定向到登录屏幕，显示所需页面

1. 用户点击书签
2. GET/secret -> 302 到/processLogin
3. GET/processLogin 通过重定向 -> 200，登录表单显示action="/secret"
4. POST/secret -> 302 到/secret
5. GET/secret -> 200，显示 secret 资源

分析:同选项2+4的问题。

选项 5:???

我还缺少另一种技术吗？

一般来说，您会推荐以下哪些技术？

另见

What is correct HTTP status code when redirecting to a login page? What kind of HTTP redirect for logins? HTTP response with redirect, but without roundtrip?

Answer 1

选项 1 和 3 不遵循 HTTP RFC因为“ secret 显示登录表单”与 200 GET 响应相矛盾，其中“响应中发送了与所请求资源对应的实体”。

选项 2 可以。所有现代浏览器都支持 302 on POST，许多基于 REST 的框架(如 RoR)积极使用它。或者，在“302 to/login”中，您已经可以创建 session (cookie)并将 URL 存储在 session 中，以避免在 GET 参数中传递原始 URL。从可用性的角度来看，您也可以在登录页面上显示适当的消息(我认为 URL 不匹配在这里无关紧要 - 您无论如何都不能让用户看到内容)。

选项 4:当您 POST 到/secret 时，HTTP RFC 希望您“接受请求中包含的实体作为请求行中 Request-URI 标识的资源的新下属”，但您只是做的是登录而不是在/secret 下创建任何新内容。

因此，根据 HTTP RFC，您最好的选择是选项 2。其实选项2也符合POST->Redirect->GET design pattern ，这有助于解决为 POST 资源添加书签 URL 时的不可预测性问题。