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

[badboy-tian]

New Issue Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and Parse Dashboard.

Issue Description

When Parse Dashboard is deployed with multiple replicas behind a load balancer that does not provide sticky sessions, login attempts fail with the CSRF error message “CSRF token validation failed. Please refresh the page and try again.” The issue disappears immediately when all requests are routed to a single replica.

Steps to reproduce

1. Deploy Parse Dashboard (npm package parse-dashboard 8.0.0) together with Parse Server behind Traefik Ingress in a Kubernetes (k3s) cluster.
2. Set the Parse Dashboard deployment replica count to 2 and use a load balancer without sticky sessions (round-robin).
3. Access https://<host>/dashboard/login, enter a configured username and password, then submit the form.
4. Observe the 403 response and the CSRF error message. Refreshing the page sometimes succeeds because the next request may hit the same pod.

Actual Outcome

• Browser shows CSRF token validation failed. Please refresh the page and try again. after submitting the login form.
• Dashboard pod logs contain EBADCSRFTOKEN entries.

Expected Outcome

• Login should succeed, or official documentation should explicitly state that Parse Dashboard requires sticky sessions or a shared session store when running multiple replicas.

Environment

Dashboard

• Parse Dashboard version: 8.0.0
• Browser (Safari, Chrome, Firefox, Edge, etc.): Safari 18.1 / Chrome 129
• Browser version: Safari 18.1 (macOS 15.1) / Chrome 129.0.6668.90

Server

• Parse Server version: 8.4.0
• Operating system: Alpine Linux (container)
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): Self-hosted k3s cluster

Database

• System (MongoDB or Postgres): MongoDB
• Database version: 6.0
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): Self-hosted MongoDB service

Logs

Relevant snippet with VERBOSE=1:

[error] CSRF token mismatch: EBADCSRFTOKEN (login POST)

If the deployment is scaled down to 1 replica or sticky sessions are enabled (Traefik sticky cookie or Kubernetes sessionAffinity: ClientIP), the issue no longer occurs.

[parse-github-assistant]

🚀 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.

[badboy-tian]

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 ?

[mtrezza]

@coderabbitai what fix do you suggest for this issue?

[coderabbitai]

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?

[mtrezza]

@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?

[coderabbitai]

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?

[coderabbitai]

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?

[mtrezza]

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

[coderabbitai]

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?

[mtrezza]

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

[coderabbitai]

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.

[mtrezza]

@badboy-tian if you could try out #3016 and let me know if it works...

[badboy-tian]

@mtrezza how to test the pr. I used to specify parse-dashboard: xxxx in package.json.