2

我正在使用 GWT History 支持来改进我的应用程序，并且我偶然发现了一个我不太确定该怎么做的案例。这个问题的答案不一定与 GWT 相关。

GWT 的 History 通过传递散列标签（即index.html#token）来支持功能。安全限制要求用户在实际能够访问之前登录index.html，因此他们会被发送到登录页面，并保留令牌 ( login.html#token)。到现在为止还挺好。现在用户通过了身份验证，Spring 将它们发送到index.html（默认目标）并消除#token了 URL 的一部分。

如何强制 Spring Security 维护令牌并将我新认证的用户发送到他们请求的页面（index.html#token）？由于我已经让 Spring Security 身份验证工作，我宁愿不重组我的应用程序处理登录的方式。

4

3 回答 3

4

经过大量挖掘，我在Spring 的 Jira上找到了答案。正如 Colin Alworth 所说，该令牌实际上并不是请求的一部分，因此 Spring Security 永远不会在服务器端看到它，因此无法使用它来确定最终 URL。所以我使用的方法是将哈希（客户端）附加到j_spring_security_check，使其成为j_spring_security_check#token. 现在令牌可以很好地传递，让我有一个安全的应用程序和工作令牌。

感谢您的帮助 Colin，您的回答让我朝着正确的方向思考。

于 2012-11-13T20:05:48.363 回答
3

正如您所指出的，服务器不会将此令牌视为 GET/POST 请求的一部分，它只能由浏览器看到。我过去看到的最佳解决方法是让登录页面记录当前的window.location.hash，并将其与登录表单一起传递（假设将发生重定向以保留散列），或者作为登录参数到服务器，以便它可以正确重定向。

于 2012-01-22T04:11:39.290 回答
0

这是发生的事情，它可能会帮助您解决问题：

  1. 将未经身份验证的用户从 index.html 发送到 login.html 很可能实现为 HTTP 3xx 重定向，这就是浏览器保留哈希片段 (#token) 的原因。
  2. 一旦他们登录，spring 将它们从 login.html 发送到 index.html，而不是通过 3xx 重定向，因此浏览器不会保留令牌。

一种解决方案是将令牌注入 index.html，然后使用 GWT 获取它。另一种方法是让 login.html -> index.html 成为 3xx 重定向（如果 spring 允许的话）。

于 2012-01-22T10:50:49.583 回答