feat(login): IdP-labelled SSO buttons + subtitle/footer that adapt to available methods

[BorisTyshkevich]

Follow-ups from the credentials-login work (#16) and the otel SSO-only deploy.

Changes

1. IdP-labelled SSO button. The single-IdP case showed a generic "Continue with SSO"; it now uses the IdP label like the multi-IdP case → "Continue with Google". (Label resolves from the config label, falling back to the issuer host — see note below.)
2. Adaptive subtitle + footer. They were hard-coded to mention credentials even when the credentials path was hidden. Now they reflect what's actually offered:
   • SSO + credentials → "Use single sign-on for this server, or connect with ClickHouse credentials." · OAuth · credentials
   • SSO-only (basic_login:false) → "Use single sign-on for this server." · OAuth ← the bug you spotted on otel
   • credentials-only (no idps) → "Connect with your ClickHouse username and password." · credentials
   • neither → "No sign-in method is configured…" · —

Note for deployments

Because the button is now label-driven, a config without a label shows the issuer host ("Continue with altinity.auth0.com"). Clusters should set a friendly label per IdP (e.g. github.demo → "GitHub", antalya → "Google"). otel's config already got "label": "Altinity SSO".

Tests

login.js stays at 100%; new suite covers the four method combinations + the config-load-failure path. Full suite green.

Verified

Deployed to otel (SSO-only, basic_login:false): button "Continue with Altinity SSO", subtitle has no credentials phrase, footer "OAuth", no credentials form; SSO sign-in still works.

🤖 Generated with Claude Code

https://claude.ai/code/session_01QennTvGKAtJZrv9EpQagef

[BorisTyshkevich]

Added two more login-screen improvements to this PR (and merged latest main, incl. #19):

Removed the "Sign in" title + subtitle entirely — no value, just took space; the brand block is heading enough. The footer tag still adapts (OAuth · credentials / OAuth / credentials / —) and the divider still shows only when both methods exist.

?host= URL param → pre-fills Advanced → Server address, opens Advanced, and disables the SSO buttons (SSO only targets the serving host) — the link drops you straight into credential sign-in for that server. Generalized: any non-empty host field disables SSO and makes credentials the active path (Target row reads "credentials"). app.hostHint reads it from the URL.

README updated; login.js stays at 100% (suites for the footer combinations, the ?host=/custom-host behaviour, and IdP labels).

Verified live:

• github.demo …/sql?host=antalya.demo.altinity.cloud → Advanced open + host prefilled, SSO disabled, Target "antalya.demo… · credentials", no title/subtitle.
• otel (SSO-only) → "Continue with Altinity SSO", footer "OAuth", no title/subtitle, no credentials form.

Note: buttons are label-driven, so a config without label shows the issuer host (github.demo → "altinity.auth0.com"). Set label per IdP (github.demo → "GitHub", antalya → "Google"); otel has "Altinity SSO".

[BorisTyshkevich]

Resolved the "config without a label shows the issuer host" follow-up — but in code, not by editing the cluster configs.

The demo clusters' config.json is served inline in the handler XML, which lives in CHOP-managed ConfigMaps (chi-*-common-configd, owned by ClickHouseInstallation). Editing it means a CHI/ConfigMap change → operator reconcile → possible pod restart — and github.demo crashes on restart (revoked-S3-backup-key landmine). Not worth that for a button label.

Instead, oauth-config.js now derives a friendly label when none is set: explicit label → Auth0 authorize_params.connection (github → "GitHub") → known issuer host (accounts.google.com → "Google") → issuer host. So an asset-only deploy fixes both:

• github.demo (connection=github) → "Continue with GitHub" ✓ (verified live)
• antalya (issuer accounts.google.com) → "Continue with Google" ✓ (verified live)
• otel keeps its explicit "label": "Altinity SSO".

No server-side config change, no restart. oauth-config.js stays at 100%.