[BUG] Shortlinks to other Tenants do not work

[jgough]

What is the bug?
When visiting a shortlink URL, the tenant specified in the URL seems to be ignored and it tries to load the shortlink in the current tenant.
This seems related to #1012

How can one reproduce the bug?
Steps to reproduce the behavior:

1. In a cluster with more than one tenant, log into Dashboards
2. Go to a page such as Discover, then click at the top Share -> Short URL -> Copy link
3. Navigate to a different Tenant
4. Open a new tab and paste the copied URL (which has a parameter ?security_tenant=first_tenant_name
5. Note that the link does not work and the Tenant is not switched. It attempts to load the goto URL from the 2nd Tenant selected in step 3 instead of the first tenant specified in the URL. This results in an error

What is the expected behavior?
The URL should work and link to the page in the correct tenant as specified in the URL

What is your host/environment?

• OS: Linux / Docker
• Version: 2.3.0
• Plugins: Security Plugin

[jgough]

Looks like #123 may be of interest here

[Leannelb]

This has been resolved on elastic search version 2.3.0.
The fix was initiated in this PR and tested in version 2.3.0. When switching tenants from a short link, the tenant is now remembered.

[jgough]

I can confirm that this bug still exists in OpenSearch 2.6.0

[Leannelb]

Thanks @jgough I can retest on 2.6.0 and implement the fix.

[leanneeliatra]

To explain how this functionality is currently working:

1. When a short URL (with parameter for security_tenant) is pasted into a new tab i.e. http://localhost:5601/goto/b9da0172f96bd51ead2ee96afcca2dc2?security\_tenant=global
2. It triggers tenant_resolver.ts found in plugins/security-dashboards-plugin/server/multitenancy/tenant_resolver.ts
3. tenant_resolver.ts retrieves the tenant from the node backend. At this point, we now have the tenant.
4. When we come to setting up/rendering the top navigation, we fetch the tenant information again, from the front end this time. In fetchAccountInfoSafe we get the data of the tenant and user. Keep in mind we already have the correct tenant info from step 3. We then fetchCurrentTenant, getting the tenant information again, but from the frontend.
5. We go on to check if the tenant is in the URL in the function when checking if tenantSpecifiedInUrl()
6. The getSavedTenant() then fetches the tenant from the localstorage and assigns the value to savedTenant
7. At this stage, we were overriding the tenant with the value from the localstorage, savedTenant.

Therefore the tenant from the URL is being over wrote with the local storage value

[leanneeliatra]

If we just stopped the re-write of the tenant from local storage, it solves the issue but, it seems like we are still using localStorage to keep track of the last used tenant.

Even without a tenant query parameter we see the following flow of operation:

1. User logs in
2. The node backend determines what tenant should be set and references the opensearch_dashboards.yml config to determine this:  opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
3. That specifies the user should be in the Private tenant in this case.
4. The browser however has stored that I was in the global tenant last time I was here, which leads to
5. The frontend sending a request to the backend to change the tenant to global
6. The browser reloads

So to propose other solutions:

1. We leave the tenant logic as it is, and instead try to make sure the tenant parameter is retained after a short link is resolved
2. Or, we move the last used tenant to a separate cookie. (My preferred solution, but would require changes to the Dashboards Core, or a "hack" for cooke compression issue).
3. Or we store the tenant in the authentication cookie, and then make sure that we don't empty the cookie completely when the user logs out (I believe this is what we do in our plugin). This isn't optimal, since the cookie lifetime is probably bound to the browser session.

Do you have any guidance on what solution you may prefer to resolve this issue? Thanks.

[rayangou]

This bug still exists in OpenSearch 2.8.0

[lihaige01]

This bug still exists in OpenSearch 2.16.0