java - GWT 应用程序是否受益于 session 集群？

Question

许多 Java PaaS(例如 CloudBees session stores )提供 session 集群/存储，这样用户在特定请求上路由到哪个服务器节点并不重要，所有服务器节点共享相同的存储 session 数据，因此任何服务都可以服务任何客户端请求。

我想知道这如何应用于客户端 MVC、单页应用程序(例如 GWT 应用程序)。

使用 GWT，大多数应用程序都以 JavaScript 形式在客户端执行。通常，客户端访问服务器(通过 GWT-RPC 或 RequestFactory)的唯一时间是客户端需要数据时，在这种情况下，它会在后台对 GWTServlet 进行特殊调用。

我对共享 session 存储的理解是，它适用于 HttpServlet 以及客户端(请求)和服务器(响应)之间的来回对话。但这似乎并不真正适用于 GWT 领域。

所以我问:我的 GWT 应用程序可以从上述应用程序 session 存储中受益吗？ 为什么或为什么不？如果是这样，我们非常感谢具体的例子!提前致谢!

示例:

我有一个应用程序，允许客户端用户执行某些操作:

public class BackOfficeServlet extends HttpServlet {
    @Override
    public void doPost(HttpServletRequest request, HttpServletResponse response) {
        User u = getUserFromRequest(request);
        Action a = getActionFromRequest(request);

        // If the user is allowed to do the action, then do it.
        if(UserActionAuthenticator.actionIsAllowed(u, a))
            a.execute(u, request);
    }
}

如何/在何处使用 HttpSession 来添加上述代码示例中未提供的安全性或功能？

Answer 1

仅当您使用 session 存储某些数据时，使用 session 集群才有意义。问你:你需要在服务器端 session 中保存一些东西吗？如果答案是否定的，则也无需使用 session 集群。 GWT 是关于有状态客户端的。大多数时候，您可以通过直接在浏览器中保存 session 数据来消除对服务器端 session 的需要。我给你一个我不想这样做的例子(在这种情况下 session 集群将很有用):

假设您的应用程序是一个后台。每个用户都必须登录，并且可以具有不同的角色。通常，包含角色的列表将出现在客户端(以便能够显示/隐藏某些 UI 控件)和服务器端(链接到 session ，以便在服务器端进行两次相同的检查)。您不能信任客户端的角色，因为最终用户可能会直接在浏览器中修改它们(即使在缩小的 JS 情况下这是非常非常复杂的任务)。这里有两个选项:1) 使用服务器端 session 2) 模拟服务器端 session (在每个 RPC 调用中发送一些自定义 session token ，然后每次重新加载用户角色)。我更喜欢第一个选项，它使我能够重用现有的安全库，例如 Spring Security(为我节省大量时间/错误)。您可以根据您的需要选择第二个选项(您的项目有足够的资源来实现和测试您自己的服务器端 session 模拟和安全方面的实现，从而使服务器端完全无状态)。

总结一下:

1. 您有一些敏感的 session 数据 -> 将它们存储在服务器 session 中 -> 您需要 session 集群
2. 您的 session 数据不敏感/您根本没有它们 -> 将它们存储在浏览器中/没有任何存储 -> 您不需要 session 和 session 集群
3. 您有一些敏感的 session 数据 -> 将它们存储在服务器端的某个位置，并使用某种自定义 session 模拟技术为每个请求重新加载它们 -> 您不需要 session 集群(但与选项 1 相比，您需要更多时间来完成此操作)。

编辑。在上面的代码示例中，您可能会遇到以下潜在问题:

1. 用户以 user1 身份登录(具有 ROLE_USER 权限)。
2. 他会以某种方式向内部 user2(具有 ROLE_ADMIN 权限)发出请求，并且某些操作只有在您具有 ROLE_ADMIN 权限时才能执行。
3. 即使 user1 没有相应的权限，也会执行此操作。

问题的原因是用户对象来自不受信任的来源(请求)并且可以由最终用户修改。我们可以将他存储在服务器端，而不是将其存储在客户端，例如使用服务器端 session :

public class BackOfficeServlet extends HttpServlet {
    @Override
    public void doPost(HttpServletRequest request, HttpServletResponse response) {
        User u = getUserFromSession(request.getSession(false));
        Action a = getActionFromRequest(request);

        if(UserActionAuthenticator.actionIsAllowed(u, a))
            a.execute(u, request);
    }
}

现在我们可以信任用户对象，因为最终用户无法更改 session 对象。