[BUG] Multitenancy: separate tenants cannot be used in different browser tabs

[neodescis]

Describe the bug
If I have two browser tabs open, and I select Tenant A in one tab, and then select Tenant B in the second tab, requests made in the first tab will get mapped to the tenant that was selected in the second tab. So, in the first tab, even though it says Tenant A is the current tenant, all saved objects that are pulled up will in fact be from Tenant B.

To Reproduce

• Configure Dashboards to have two or more tenants
• Change to one of those tenants (Tenant A)
• Open a new tab
• Select another tenant in the 2nd tab (Tenant B)
• Go back to the first tab and search for dashboards, visualizations, etc.

Expected behavior
The first tab should return results from Tenant A

Actual behavior
The first tab returns results from Tenant B, despite saying Tenant A is the current tenant

OpenSearch Version
2.18.0

Dashboards Version
2.18.0

Plugins

• Security

Screenshots

If applicable, add screenshots to help explain your problem.

Host/Environment (please complete the following information):

• OS: Windows 11
• Browser and version: Chrome 131

Additional context
I believe this is because the selected tenant is being saved in a cookie, which is being reused across browser tabs

[derek-ho]

Thanks for creating this issue @neodescis. Did a quick search and it seems like tenancy is using localstorage:

security-dashboards-plugin/public/utils/storage-utils.tsx

Line 71 in ded4012

return getValue<string>(localStorage, TENANT_CATEGORY, TENANT_SAVED_KEY);

. A quick fix may be to switch this to sessionstorage. We would want to see if there was any specific reason localstorage was used in the first place.

[neodescis]

It's actually using session storage and the auth cookie to store the current tenant. See here and here for the server-side cookie storage. Both the cookie and local storage are problematic. I've actually worked through a comprehensive solution that:

1. Removes the tenant from the cookie entirely
2. Stores the tenant in both local storage (used to remember the tenant when opening a new tab/window) and session storage (used to remember the current tenant within the current tab/window, regardless of what was selected on another tab/window)
3. Uses an HTTP interceptor to set the securitytenant header on all API requests to the tenant currently in session storage

I'm still going through edge cases, but so far this seems like a good solution. It is, however, a very invasive change. Do you think this is an approach that would be acceptable to put into a pull request?