An OIDC-only SSO setup returned 500 from the endpoint the login page loads, so the whole UI was unreachable

The issue, in one line

get_sso_info read settings[‘sp’] unconditionally, and OIDC settings carry no SAML sp section, so the login page got a 500 and password login was gone with it. The issue.

The cause

The SSO settings model stores a per-provider settings dict. The SAML provider fills in an sp section with the service provider entity id, and the OIDC provider does not. get_sso_info indexed settings[‘sp’] before building the response, so with openid_connect the lookup raised KeyError and the view returned 500. The login page loads this endpoint to decide whether to show the SSO button and which provider to post to, so a 500 there takes the whole page down, not only the SSO path.

Where it lives

• backend/global_settings/views.py, get_sso_info indexed sso_settings.settings[‘sp’].get(‘entity_id’) with no guard for a missing section or a null settings value
• backend/global_settings/tests/test_sso_info.py, new test file, 65 lines, covering a SAML config, OIDC settings without an sp key in three shapes including null, and OIDC without a provider id

The fix, planned in the free diagnosis

• Read the sp section defensively, treating a null settings value and a missing key as an empty dict.
• Fall back to provider_id and then provider when there is no SP entity id, because the login page posts this value to the redirect endpoint and an empty string would be rejected there and break the SSO button again.
• Cover the three settings shapes with a parametrised test that asserts the returned sp_entity_id is openid_connect for OIDC.

How it’s proven, in the sprint

• The new test file run against main gives 3 failed, KeyError ‘sp’ plus a TypeError for null settings, and 4 passed with the fix, on uv run pytest global_settings/tests/test_sso_info.py.
• The parametrised case covers {}, a settings dict with only server_url, and None, and asserts status 200 and sp_entity_id openid_connect in each.
• GitHub shows CLAAssistant, Analyze (actions), Analyze (javascript-typescript), Analyze (python), GitGuardian and Plumber as success. No workflow ran pytest, so the pass and fail counts above are the author’s local run quoted in the PR body.

What wasn’t tested, said up front

The full backend suite, the redirect endpoint that consumes sp_entity_id, and the login page in a browser. SAML behaviour is covered only by the one happy-path case, and no other provider was exercised.

What happened next, after the sprint

It was merged on 2026-10-14 about 8 days after it opened, with 71 lines added and 1 removed. Open the pull request.