webui: Fix OIDC login Sign In disabled by always-required credentials

[tlsalmin]

Context

Tried to utilize OIDC for authentication (Authentik as the IdP) but hit an issue that the login button could not be clicked after OIDC was chosen. Backend OIDC was fine (GET /oidc/login returned 302 to the IdP with correct redirect_uri / PKCE); the problem was only in the login UI.

I could not open an issue on GitLab (account signup blocked), so this is a GitHub PR as described in CONTRIBUTING.md for that case.

Disclosure: This fix was implemented with Grok (xAI). I (Tomi) have not carefully reviewed the change line-by-line myself; I verified that applying the equivalent fix unblocked OIDC login for me in a real deploy (Stork 2.5.0 + Authentik). Please treat the patch as needing a normal maintainer review.

Summary

When OIDC is selected as the authentication method, the login form still keeps identifier / secret as required, so the form stays invalid. Combined with non-form UI state only being refreshed from the Select onChange path (not always on method load), OIDC is easy to leave unusable—especially with a single OIDC method or a restored OIDC preference.

Also fixes the OIDC link using a relative oidc/login?… href (no leading /), which is fragile behind reverse proxies / path resolution.

Changes

• Always call updateNonFormLabel() for the selected method after methods load (OIDC-only and restored preference included).
• Clear required validators on identifier/secret for OIDC; restore them for form methods (local/LDAP).
• Use absolute path /oidc/login?returnUrl=… for the non-form login link.
• Unit tests: OIDC-only method list, localStorage restore of OIDC, select OIDC (absolute href + valid form) and switch back to local (required validators return).

Test plan

• With local + OIDC methods: select OIDC → non-form button visible and clickable; form valid without username/password.
• Click OIDC button → browser navigates to /oidc/login?returnUrl=… → IdP (e.g. Authentik).
• Select local/LDAP again → identifier/secret required; Sign In disabled until filled.
• OIDC as sole method: non-form UI enabled on first load (no Select change needed).
• Restore selected-auth-method=oidc from localStorage → same as selecting OIDC.
• Existing local/LDAP sign-in still works.
• Unit tests for login-screen.component.spec.ts.

Environment where this was observed

• Stork server 2.5.0
• OIDC IdP: Authentik
• UI behind reverse proxy

Notes

• GitLab issues are disabled for new signup in my case; happy to open/link a GitLab issue if someone grants access or files one for this.
• Related closed work (OIDC feature itself, not this UX bug): GitLab #2480, #2465.

[tomaszmrugalski]

Hey @tlsalmin, thanks for using Stork, for the patch and sorry to hear about your problems. We're getting lots of spammy accounts, so our anti-spam defenses are cranked up high and they occasionally block legitimate users.

I just managed to create an account using my private e-mail. I've asked our Ops team to investigate.

[pzadroga]

Hi @tlsalmin, thanks for reporting this! I'm trying to better understand what happened. I tried to replicate the problem in my local testing environment, but I was unable to do so. Could you answer these questions?

1. When the problem happens, does the UI display "Sign In" button or "Log in with..." button?
2. Is OpenID Connect the only authentication method displayed in the "Choose a method" dropdown?
3. If possible, could you check in your browser Developer Tools what the response is to the GET /api/authentication-methods REST API endpoint when the Stork Login screen is loaded?

Thanks!

[tomaszmrugalski]

hey @tlsalmin you might want yo check your mail.