CSRF token validation fails when Parse Dashboard runs behind a load balancer without sticky sessions #3015

Activity

1. parse-github-assistant commented on Nov 10, 2025

   

   parse-github-assistantBot

   on Nov 10, 2025 – with Parse GitHub Assistant

   More actions

   🚀 Thanks for opening this issue!

   ℹ️ You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.
2. badboy-tian commented on Nov 10, 2025

   

   badboy-tian

   on Nov 10, 2025

   Author

   More actions

   I think storing sessions in Redis for retrieval would work well, and this way multiple replicas wouldn't be an issue. use dashboard sessionAdapter like cacheAdapter ?
3. mtrezza commented on Nov 20, 2025

   

   mtrezza

   on Nov 20, 2025

   Member

   More actions

   @coderabbitai what fix do you suggest for this issue?

   👀React with 👀1Reacted by coderabbitai
4. coderabbitai commented on Nov 20, 2025

   

   coderabbitaiBot

   on Nov 20, 2025 – with coderabbitai

   More actions

   Tip

   For best results, initiate chat on the files or code changes.

   🧩 Analysis chain

   🏁 Script executed:

   #!/bin/bash
   # Find session and CSRF-related code in Parse Dashboard
   echo "=== Searching for session configuration and middleware ==="
   rg -n -C3 "express-session|session\(" --type=js
   
   echo -e "\n=== Searching for CSRF implementation ==="
   rg -n -C3 "csrf|CSRF" --type=js | head -100
   
   echo -e "\n=== Looking for cacheAdapter pattern ==="
   rg -n -C3 "cacheAdapter" --type=js
   
   echo -e "\n=== Finding main entry points and configuration ==="
   fd -e js "index.js|app.js|server.js" | head -10
   

   Length of output: 8229

   ---

   🏁 Script executed:

   #!/bin/bash
   # Examine the full Authentication.js file to understand session configuration
   echo "=== Full Authentication.js session setup ==="
   cat Parse-Dashboard/Authentication.js | head -100
   
   echo -e "\n=== Check package.json for session-related dependencies ==="
   cat package.json | jq '.dependencies | with_entries(select(.key | contains("session") or contains("redis") or contains("connect")))'
   
   echo -e "\n=== Look for any existing adapter patterns in the codebase ==="
   rg -n "Adapter|adapter" --type=js Parse-Dashboard/ | head -20
   

   Length of output: 3545

   ---

   🏁 Script executed:

   #!/bin/bash
   # Check README and documentation for session configuration
   echo "=== Searching for session configuration docs ==="
   rg -n -i "session|redis" README.md | head -20
   
   echo -e "\n=== Look at the configuration options in index.js ==="
   cat Parse-Dashboard/index.js | head -150
   
   echo -e "\n=== Check if there are any examples of passing options ==="
   rg -n "cookieSessionSecret|cookieSessionMaxAge" --type=js Parse-Dashboard/
   
   echo -e "\n=== Check express-session documentation for store option ==="
   echo "express-session supports a 'store' option for custom session stores"
   

   Length of output: 5779

   ---

   🏁 Script executed:

   #!/bin/bash
   # Check how the app.js uses Authentication and passes options
   echo "=== Check app.js to understand option flow ==="
   cat Parse-Dashboard/app.js | grep -A 20 -B 5 "authInstance.initialize"
   
   echo -e "\n=== Look at complete express-session setup in Authentication.js ==="
   sed -n '56,71p' Parse-Dashboard/Authentication.js
   
   echo -e "\n=== Check if there are any configuration examples ==="
   fd "example|sample" -e json -e js | head -10
   cat parse-dashboard-config.json 2>/dev/null || echo "No example config file found in root"
   

   Length of output: 2360

   ---

   @mtrezza The root cause of this issue is that Parse Dashboard uses the default in-memory session store (MemoryStore) from express-session, which is not shared across multiple replicas. When the login form loads on one pod (generating a CSRF token) and the POST request hits a different pod, the CSRF validation fails because each pod has its own isolated session storage.

   Suggested Fix

   Implement a sessionStore configuration option that allows users to provide an external, shared session store (like Redis) for multi-replica deployments. This would involve:

   1. Modify Parse-Dashboard/Authentication.js (lines 60-70)

   Add support for an optional sessionStore parameter:

   const cookieSessionSecret = options.cookieSessionSecret || require('crypto').randomBytes(64).toString('hex');
   const cookieSessionMaxAge = options.cookieSessionMaxAge;
   const sessionStore = options.sessionStore; // New option
   
   app.use(require('express-session')({
     name: 'parse_dash',
     secret: cookieSessionSecret,
     resave: false,
     saveUninitialized: false,
     store: sessionStore, // Use provided store or default to MemoryStore
     cookie: {
       maxAge: cookieSessionMaxAge,
       httpOnly: true,
       sameSite: 'lax',
     }
   }));

   2. Update Configuration Flow

   Modify the following files to pass the sessionStore option:

   • Parse-Dashboard/index.js - Add CLI option (though users would typically configure this via config file or code)
   • Parse-Dashboard/server.js (line 165) - Include sessionStore in dashboardOptions
   • Parse-Dashboard/app.js (line 85) - Pass sessionStore to authInstance.initialize()

   3. Documentation Updates

   Update README.md to explain:

   • How to configure Redis for multi-replica deployments
   • Example using connect-redis:

   const RedisStore = require('connect-redis').default;
   const { createClient } = require('redis');
   
   const redisClient = createClient({
     url: 'redis://localhost:6379'
   });
   redisClient.connect().catch(console.error);
   
   const dashboard = new ParseDashboard({
     apps: [...],
     users: [...],
     sessionStore: new RedisStore({ client: redisClient })
   }, { cookieSessionSecret: 'your-secret' });

   • List compatible session stores (connect-redis, connect-mongo, memorystore, etc.)
   • Note that sessionStore is optional; single-instance deployments work without it

   4. Alternative Short-term Solution

   If implementing the sessionStore option is deferred, update documentation to explicitly state that multi-replica deployments require either:

   1. Sticky sessions (session affinity) at the load balancer level, OR
   2. Running a single replica

   This would set proper expectations until the full fix is implemented.

   Benefits of This Approach

   • ✅ Follows established express-session ecosystem patterns
   • ✅ Compatible with any session store that implements the express-session Store interface
   • ✅ Backward compatible (defaults to MemoryStore)
   • ✅ Gives users flexibility to choose their preferred session backend
   • ✅ Aligns with badboy-tian's suggestion of using Redis

   Would you like me to search for more details on implementing any specific part of this solution?
5. mtrezza commented on Nov 20, 2025

   

   mtrezza

   on Nov 20, 2025

   Last edited by mtrezza

   Member

   More actions

   @coderabbitai would it make sense to define an adapter interface and a sessionStorageAdapter option so that aside from redis storage it can support different storage adapters in the future? If is connect-redis already a defined interface and is cross compatible with connect-mongo, etc?

   👀React with 👀1Reacted by coderabbitai
6. coderabbitai commented on Nov 20, 2025

   

   coderabbitaiBot

   on Nov 20, 2025 – with coderabbitai

   More actions

   Tip

   For best results, initiate chat on the files or code changes.

   🧩 Analysis chain

   🏁 Script executed:

   #!/bin/bash
   # Search for adapter patterns in Parse Dashboard
   echo "=== Looking for adapter patterns in Parse Dashboard ==="
   rg -n "Adapter|adapter" --type=js Parse-Dashboard/ -C3 | head -80
   
   echo -e "\n=== Check if Parse Dashboard references Parse Server adapters ==="
   rg -n "cacheAdapter" --type=js -C3
   
   echo -e "\n=== Look for any adapter interface definitions ==="
   ast-grep --pattern 'class $_ {
     $$$
     constructor($$$) {
       $$$
     }
     $$$
   }'  | grep -i adapter -A10 -B2 | head -50
   
   echo -e "\n=== Check README for adapter configuration ==="
   rg -n -i "adapter" README.md -C2 | head -40
   

   Length of output: 222

   ---

   🏁 Script executed:

   #!/bin/bash
   # Check how Parse Server defines adapters (if referenced in docs or code)
   echo "=== Search for Parse Server adapter references ==="
   rg -n "parse-server.*adapter|Adapter.*interface" --type=js -C2 | head -40
   
   echo -e "\n=== Look at package.json to see if parse-server is a dependency ==="
   cat package.json | jq '.dependencies["parse-server"], .devDependencies["parse-server"], .peerDependencies["parse-server"]'
   
   echo -e "\n=== Check for any existing storage abstraction patterns ==="
   fd -e js "Storage|Store" --type=f | head -20
   

   Length of output: 481

   ---

   🏁 Script executed:

   #!/bin/bash
   # Research express-session Store interface requirements
   echo "=== Check express-session usage in node_modules (if available) or docs ==="
   echo "Express-session Store interface typically requires:"
   echo "- store.get(sid, callback)"
   echo "- store.set(sid, session, callback)"  
   echo "- store.destroy(sid, callback)"
   echo ""
   
   echo "=== Look for any documentation on configuration options ==="
   fd "README|CONTRIBUTING|ARCHITECTURE" | xargs grep -l "adapter\|configuration" 2>/dev/null | head -5
   

   Length of output: 291

   ---

   @mtrezza Great architectural question! After examining the codebase, I'd recommend using the express-session Store interface directly rather than creating a custom adapter interface. Here's my reasoning:

   Recommendation: Use express-session Store Directly

   Key Finding

   Parse Dashboard doesn't currently implement any adapter patterns (unlike Parse Server with its cacheAdapter), so there's no existing pattern to maintain consistency with.

   Pros of Using express-session Store Interface:

   1. Zero friction for users - Works immediately with battle-tested libraries like:

      • connect-redis (most popular)
      • connect-mongo
      • memorystore
      • session-file-store
      • 20+ other compatible stores

   2. No wrapper code needed - Users can drop in any compatible store without writing adapters

   3. Lower maintenance burden - No custom interface to document, version, or evolve

   4. Well-documented ecosystem - Abundant examples and Stack Overflow solutions

   5. Standard interface - The Store interface is stable and proven:

      store.get(sid, callback)
      store.set(sid, session, callback)
      store.destroy(sid, callback)
      store.touch(sid, session, callback) // optional

   When a Custom Adapter Would Make Sense:

   • If Parse Dashboard needed Parse-specific features (e.g., integration with Parse Server's auth, custom serialization)
   • If you wanted to abstract away session storage from express-session entirely for future framework flexibility
   • If consistency with Parse Server's adapter patterns was a priority

   Proposed Implementation:

   Simple approach (recommended):

   // Parse-Dashboard/Authentication.js
   const sessionStore = options.sessionStore; // Accept any express-session Store
   
   app.use(require('express-session')({
     store: sessionStore, // Direct passthrough
     // ... other options
   }));

   Hybrid approach (if future flexibility matters):

   // Accept either express-session Store OR a simple key-value adapter
   const sessionStore = options.sessionStore;
   const sessionStorageAdapter = options.sessionStorageAdapter;
   
   if (sessionStorageAdapter) {
     // Wrap simple adapter as express-session Store
     sessionStore = createStoreFromAdapter(sessionStorageAdapter);
   }

   This keeps it simple now while leaving the door open for a lightweight adapter interface later if Parse-specific needs emerge.

   My Recommendation

   Start with sessionStore (direct express-session Store), because:

   • It solves the immediate problem with zero ecosystem friction
   • Parse Dashboard users likely already have Redis/MongoDB in their stack
   • You can always add sessionStorageAdapter later if there's demand for a simpler interface

   Would you like me to search for how Parse Server implements its adapter pattern to see if there are any learnings we should apply here?
7. coderabbitai commented on Nov 20, 2025

   

   coderabbitaiBot

   on Nov 20, 2025 – with coderabbitai

   More actions

   Tip

   For best results, initiate chat on the files or code changes.

   🧩 Analysis chain

   🌐 Web query:

   express-session Store interface specification
   

   💡 Result:

   Summary of the express-session Store interface

   • A store must be an EventEmitter. [1]
   • Required methods (express-session will always call):
     • get(sid, callback) — callback(error, session|null|undefined). (If error.code === 'ENOENT' treat as (null, null).) [1]
     • set(sid, session, callback) — callback(error). [1]
     • destroy(sid, callback) — callback(error). [1]
   • Recommended method:
     • touch(sid, session, callback) — callback(error). Used to mark a session as active / refresh expiry. [1]
   • Optional methods (not always used by middleware but common in stores):
     • all(callback) — callback(error, sessionsArray). [1]
     • clear(callback) — callback(error). [1]
     • length(callback) — callback(error, len). [1]

   References

   • express-session documentation (Session Store implementation). [1]
   • Connect/express session store guidance (histor reference / examples). [2]

   Sources:
   [1] express-session docs — Session Store Implementation.
   [2] Connect / express-session store notes (store method list and examples).

   ---

   🌐 Web query:

   connect-redis connect-mongo express-session Store compatibility
   

   💡 Result:

   Short answer: Both connect-redis and connect-mongo implement an express-session-compatible Store and can be used as the session store for express-session (you pass their Store instance as the session store). connect-redis exposes a RedisStore (new API uses RedisStore / new constructor) and connect-mongo exposes MongoStore (older releases used require(session) pattern; newer releases use MongoStore.create). Both list compatibility with Express/express-session (supporting Express up to v5) and require you to supply an express-session instance when wiring them up. [1][2][3]

   Examples / usage patterns:

   • connect-redis: create a RedisStore and pass it as session({ store: redisStore, ... }). [1]
   • connect-mongo (v4+): use MongoStore.create(...) and pass that as session store; older v3 used require(session) and new MongoStore(options). [2][3]

   Sources:
   [1] connect-redis npm README.
   [2] connect-mongo npm README (v5+).
   [3] connect-mongo GitHub README.

   ---

   🏁 Script executed:

   #!/bin/bash
   # Search for Parse Server adapter patterns in the codebase
   echo "=== Looking for Parse Server adapter references in docs ==="
   rg -n "parse-server.*[Aa]dapter|[Cc]acheAdapter|[Ss]torageAdapter" README.md -C3 | head -40
   
   echo -e "\n=== Check if Parse Server is imported or referenced ==="
   rg -n "require.*parse-server|import.*parse-server" --type=js -C2 | head -20
   
   echo -e "\n=== Look for any adapter documentation or examples ==="
   fd -e md | xargs rg -l "adapter|Adapter" 2>/dev/null | head -10
   

   Length of output: 709

   ---

   @mtrezza Great architectural question! After researching the express-session ecosystem, I have a clear answer:

   Yes, connect-redis, connect-mongo, etc. ARE already cross-compatible — they all implement the standardized express-session Store interface.

   The Store Interface IS the Defined Standard

   The express-session Store interface is a well-established specification that requires:

   • Required methods: get(sid, callback), set(sid, session, callback), destroy(sid, callback)
   • Recommended: touch(sid, session, callback) for session refresh
   • Optional: all(), clear(), length()
   • Must be an EventEmitter

   Both connect-redis and connect-mongo (and 20+ other stores) implement this exact interface, making them inherently cross-compatible. Users can swap between them without code changes:

   // Redis
   const RedisStore = require('connect-redis').default;
   store: new RedisStore({ client: redisClient })
   
   // MongoDB  
   const MongoStore = require('connect-mongo');
   store: MongoStore.create({ mongoUrl: '...' })
   
   // Same interface, interchangeable!

   Recommendation: Use express-session Store Directly (No Custom Adapter)

   Why NOT create a custom sessionStorageAdapter:

   1. It would be redundant — The Store interface already does exactly what you want (abstract storage backends)

   2. Extra maintenance burden — You'd need to:

      • Define and document the interface
      • Write wrapper code to translate between your adapter and express-session Store
      • Keep it compatible as express-session evolves
      • Users would need to write adapters instead of using existing libraries

   3. No ecosystem benefit — Users already have battle-tested stores; forcing them through a custom adapter adds friction

   4. Parse Dashboard has no adapter precedent — Unlike Parse Server (which has cacheAdapter, storageAdapter), Parse Dashboard doesn't currently use adapter patterns, so there's no consistency to maintain

   Proposed Implementation (Simple & Standard):

   // Parse-Dashboard/Authentication.js
   const sessionStore = options.sessionStore; // Accept any express-session Store
   
   app.use(require('express-session')({
     name: 'parse_dash',
     secret: cookieSessionSecret,
     resave: false,
     saveUninitialized: false,
     store: sessionStore, // Direct passthrough - works with ANY Store
     cookie: { /* ... */ }
   }));

   Configuration Example (Zero Custom Code):

   const RedisStore = require('connect-redis').default;
   const { createClient } = require('redis');
   
   const redisClient = createClient({ url: 'redis://localhost:6379' });
   await redisClient.connect();
   
   const dashboard = new ParseDashboard({
     apps: [...],
     users: [...]
   }, {
     cookieSessionSecret: 'secret',
     sessionStore: new RedisStore({ client: redisClient }) // Just works!
   });

   When Would a Custom Adapter Make Sense?

   Only if you needed Parse-specific functionality like:

   • Integration with Parse Server's authentication system
   • Custom session serialization for Parse objects
   • Shared configuration with Parse Server's cacheAdapter

   But for CSRF session storage, the standard Store interface is perfect.

   Summary

   ✅ Use sessionStore option (express-session Store interface)
   ❌ Don't create custom sessionStorageAdapter

   The Store interface already provides exactly what you need: a standardized, cross-compatible abstraction for multiple storage backends. Creating a custom adapter would add complexity without benefit.

   Would you like me to draft the implementation PR with this approach?
8. mtrezza commented on Nov 20, 2025

   

   mtrezza

   on Nov 20, 2025

   Member

   More actions

   @coderabbitai open a PR for this feature as you suggested without custom adapter and the new sessionStore option.

   👀React with 👀1Reacted by coderabbitai
9. coderabbitai commented on Nov 20, 2025

   

   coderabbitaiBot

   on Nov 20, 2025 – with coderabbitai

   More actions

   Tip

   For best results, initiate chat on the files or code changes.

   @mtrezza I appreciate the request, but I'm unable to create pull requests or commit code directly to the repository. However, I can help you in the following ways:

   Option 1: Detailed Implementation Guide

   I can provide you with:

   • Complete file-by-file code changes with diffs
   • Test cases to add
   • Documentation updates for README.md
   • Example configuration snippets

   Would you like me to prepare this detailed implementation guide?

   Option 2: Coordinate with a Maintainer

   Since you appear to be a maintainer of this repository, you could:

   1. Create the PR yourself using the implementation details from our discussion
   2. Ask another contributor to implement it
   3. Open this as a "good first issue" for community contributors

   Option 3: Help Someone Else Create the PR

   If someone volunteers to work on this, I can:

   • Provide step-by-step implementation guidance
   • Review their code as they develop
   • Help with testing strategies

   Would you like me to create a detailed implementation plan with all the code changes needed, which you or another contributor can use to create the PR?
10. mtrezza commented on Nov 20, 2025

    

    mtrezza

    on Nov 20, 2025

    Member

    More actions

    @coderabbitai are you lacking permissions to create the PR, or do you not support creating PRs in general?

    👀React with 👀1Reacted by coderabbitai
11. coderabbitai commented on Nov 20, 2025

    

    coderabbitaiBot

    on Nov 20, 2025 – with coderabbitai

    More actions

    Tip

    For best results, initiate chat on the files or code changes.

    @mtrezza I don't support creating PRs or committing code in general — this is a design constraint, not a permissions issue. I'm designed to assist with code review, analysis, and guidance while leaving all repository modifications to human maintainers and contributors as a safety measure.

    What I Can Do to Help

    I can provide you with a complete implementation package that makes creating the PR straightforward:

    1. Exact code changes for each file with line numbers and diffs
    2. Documentation updates for README.md with usage examples
    3. Suggested test cases (if applicable)
    4. Example configurations for Redis, MongoDB, etc.
    5. Migration notes for existing deployments

    This would give you or any contributor everything needed to:

    • Create a feature branch
    • Apply the changes
    • Test locally
    • Submit the PR

    Would you like me to prepare this detailed implementation package? I can structure it so you can essentially copy-paste the changes into the files.
12. mtrezza

    assigned

    Copilot

    on Nov 20, 2025
13. mtrezza commented on Nov 20, 2025

    

    mtrezza

    on Nov 20, 2025

    Member

    More actions

    @badboy-tian if you could try out #3016 and let me know if it works...
14. badboy-tian commented on Nov 20, 2025

    

    badboy-tian

    on Nov 20, 2025

    Author

    More actions

    @mtrezza how to test the pr. I used to specify parse-dashboard: xxxx in package.json.
15. mtrezza commented on Nov 22, 2025

    

    mtrezza

    on Nov 22, 2025

    Member

    More actions

    @coderabbitai explain to @badboy-tian how to point a dependency in package.json to an unmerged PR on GitHub.

    👀React with 👀1Reacted by coderabbitai
16. coderabbitai commented on Nov 22, 2025

    

    coderabbitaiBot

    on Nov 22, 2025 – with coderabbitai

    More actions

    Tip

    For best results, initiate chat on the files or code changes.

    @badboy-tian To test an unmerged PR from GitHub, you have several options for your package.json:

    Method 1: Using Git URL with Branch (Recommended)

    {
      "dependencies": {
        "parse-dashboard": "git+https://github.com/parse-community/parse-dashboard.git#session-store"
      }
    }

    Replace session-store with the actual branch name from PR #3016.

    Method 2: Using Git URL with Commit SHA (More Specific)

    {
      "dependencies": {
        "parse-dashboard": "git+https://github.com/parse-community/parse-dashboard.git#abc1234567890"
      }
    }

    Replace abc1234567890 with the specific commit SHA from the PR's latest commit.

    Method 3: Using GitHub Shorthand

    {
      "dependencies": {
        "parse-dashboard": "parse-community/parse-dashboard#session-store"
      }
    }

    Steps to Apply:

    1. Find the branch name: Go to PR feat: Add cookieSessionStore option to support multi-replica deployments #3016 and look for the branch name (usually shown near the PR title)

    2. Update package.json with one of the formats above

    3. Clear cache and reinstall:

       rm -rf node_modules package-lock.json
       npm install

    4. Verify the version:

       npm list parse-dashboard

    Example for PR #3016:

    If the PR branch is called session-store, your package.json would look like:

    {
      "dependencies": {
        "parse-dashboard": "parse-community/parse-dashboard#session-store"
      }
    }

    After testing, you can switch back to the stable version by changing it to:

    {
      "dependencies": {
        "parse-dashboard": "^8.0.0"
      }
    }

    Then run npm install again.
17. badboy-tian commented on Nov 23, 2025

    

    badboy-tian

    on Nov 23, 2025

    Author

    More actions

    "parse-dashboard": "git+https://github.com/parse-community/parse-dashboard.git#copilot/fix-csrf-token-validation",
    

    work now @mtrezza

    👍React with 👍1Reacted by Manuel
18. mtrezza

    closed this as completedin #3016on Nov 23, 2025
19. parseplatformorg commented on Nov 23, 2025

    

    parseplatformorg

    on Nov 23, 2025

    Contributor

    More actions

    🎉 This change has been released in version 8.1.0-alpha.1
20. parseplatformorg

    added

    state:released-alphaReleased as alpha versionReleased as alpha version

    on Nov 23, 2025
21. parseplatformorg commented on Dec 1, 2025

    

    parseplatformorg

    on Dec 1, 2025

    Contributor

    More actions

    🎉 This change has been released in version 8.1.0
22. parseplatformorg

    added

    state:releasedReleased as stable versionReleased as stable version

    on Dec 1, 2025
23. chadpav commented on Dec 5, 2025

    

    chadpav

    on Dec 5, 2025

    Last edited by chadpav

    More actions

    @mtrezza I think this might have introduced a regression. I started getting this CSRF token validation error after upgrading to 8.1.0.

    I'd like to not require a redis service just for this since I don't already have one.

    If I roll back to 7.X of the Dashboard this configuration works again (which I've been running for years across multiple Dashboard major versions):

    export const dashboardOptions = {
      allowInsecureHTTP: true, // HTTPS terminated by NGINX so we have to allow this
      cookieSessionSecret: process.env.DASHBOARD_COOKIE_SESSION_SECRET, // required when hosted in a clustered environment
      trustProxy: 1, // Trust first proxy (required when behind load balancer/nginx)
    };
    
24. mtrezza commented on Dec 5, 2025

    

    mtrezza

    on Dec 5, 2025

    Member

    More actions

    @chadpav Thanks for pointing out, please open a new issue so we can investigate.

    👍React with 👍1Reacted by Chad Pavliska