Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-99806

Ability to have user session replication between the nodes in Confluence Data Center (DC)

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Data Center - Core
    • None
    • 4
    • 2
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Problem Definition

      When running Confluence Data Center with multiple nodes, users accessing the application through a browser are expected to stick to a specific node for the duration of their session due to sticky sessions being enabled at the Load balancer end as per existing functionality/recommendation.

      If the node handling a user's session becomes unavailable, due to planned maintenance or an unexpected failure, the load balancer will route subsequent requests to another available node.

      Since certain session-related data, such as the XSRF token and websudo token, is stored locally in users' sessions on the node and not shared across nodes, some user actions (like Administration console access, page create etc.) will fail after such a node switch. This typically results in XSRF token validation errors for operations initiated after the session is redirected.

      Steps to Reproduce

      • Set up a Confluence DC cluster with two nodes: node1 and node2.
      • Suppose User is accessing Confluence through node1.
        • Remember me option was enabled when authenticating, making seraph.rememberme.cookie available for the user's session.
      • Node1 is removed from the load balancer.
      • When the user makes a regular request (e.g., opening a Confluence page), it is forwarded to node2 , and a new authentication is not required due to the remember me cookie being enabled.
      • Now the user is accessing Confluence through node2.
      • When the user starts creating a new Confluence page or accessing the Administration console, the request fails due to XSRF token validation/missing error.

      Actual Results 

      The user request requiring an XSRF or website token fails as the user session-related information was stored on Node 1, which is not part of the DC cluster. The user request is routed to Node 2, which doesn't contain the user's session-related info, containing an XSRF token or web-sudo token.

      Expected Results

      The User request should be successfully processed by the second node instead of failing with XSRF token missing related errors.

      Suggested Solution

      Confluence maintains/syncs User session-related info (like XSRF token, websudo token) across all of the nodes in the Data Center cluster so that user requests don't fail in case of a node switch.

              Unassigned Unassigned
              33df95c63117 Nitin Rastogi
              Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: