PRACTICAL FIELD GUIDE
Clear private cached data when users switch accounts
A frontend cache can display the previous user's records after the backend correctly changes identity. Cache keys and invalidation need to account for the authenticated user and project.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Include relevant identity and project context in private-data cache design.
- Clear or invalidate private records during logout and account switching.
- Test a shared browser by signing in as two disposable users consecutively.
What this looks like
ILLUSTRATIVE EXAMPLE
User B sees user A's old task list briefly because the UI reused a generic tasks cache key.
A boundary to keep clear
Backend owner policies cannot erase data your application already cached in the previous session. Protect the client state as well.
MCPBackend context
Application email/password authentication is separate from the developer dashboard login and MCP OAuth connection. The current app-user tokens are project-scoped and do not automatically expire. Do not assume built-in refresh, password reset, per-token revocation or social login; check supported behavior before designing those flows.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.