[fix] Re-initialize Dex UserManager on cluster switch and use sessionStorage for callback dexUrl

[dcharles525]

PR Checklist

• Linting Test is passing
• Code is well documented
• If applicable, a PR in the epinio/docs repository has been opened

Summary

Fixes EPINIO-577 — When clicking on one Epinio cluster (e.g. dev) while another (e.g. prod) had been previously authenticated, the login popup opened against the wrong cluster's Dex instance, routing the user to the wrong cluster or the front Rancher cluster after auth.

Occurred changes and/or fixed issues

1. utils/auth.ts — Re-initialize dexUserManager on cluster switch

EpinioAuth is a singleton. Previously login() only initialized dexUserManager if it was null, so switching from one Epinio cluster to another reused the first cluster's Dex manager (wrong authority/Dex URL). The fix re-initializes the manager whenever the target cluster's Dex URL differs from the current manager's authority. A missing await on initialiseDex was also corrected.

2. utils/auth.ts + pages/auth/verify.vue — Use sessionStorage for dexUrl in callback

verify.vue previously used document.referrer as the dexUrl when processing the Dex callback, which is empty when Dex sends a Referrer-Policy: no-referrer header. initialiseDex now writes the cluster's dexUrl to sessionStorage before opening the popup, and verify.vue reads it back. document.referrer is retained as a fallback.

Technical notes summary

• UserManager.settings.authority (from oidc-client-ts) is used to compare the current Dex URL against the target cluster's dexUrl to detect when re-initialization is needed.
• sessionStorage is used rather than localStorage so the stored dexUrl is scoped to the current browser session/tab.
• initialiseDex already handled re-initialization correctly (logs out existing user, replaces manager) — the only change needed in login() was the condition that gates the call.

Areas or cases that should be tested

1. Stand up two Epinio clusters (e.g. dev and prod) with separate Dex instances on rancher.internal
2. Log in to the prod cluster via Dex — confirm you land on prod's dashboard
3. Log out of prod, navigate to dev, and log in via Dex — confirm the popup opens against dev's Dex URL and you land on dev's dashboard
4. Reverse order: log into dev first, then prod — confirm correct behavior
5. Confirm single-cluster Dex login still works normally
6. Confirm local (non-Dex) login is unaffected

Browser used for local testing: Chrome

Areas which could experience regressions

• Single-cluster Dex login — low risk; the new authority !== dexUrl condition is a no-op when there is only one cluster, since the manager initializes correctly on first call
• sessionStorage in popup context — parent and popup share the same origin so sessionStorage is accessible; document.referrer fallback is retained if sessionStorage returns null

Screenshot/Video

Verified working on rancher.internal with dev and prod Epinio instances.