{"version":"2.1.265","anchor":"gateway-auth-backend-api-key-check-now-short-circuits-to-m","canonical_anchor":"forcelogingatewayurl-validation-loosened-from-strict-url-to","heading":"Gateway-forced login detection and validation simplified","tier":"notice","area":"Auth","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265\/e\/gateway-auth-backend-api-key-check-now-short-circuits-to-m","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.265","markdown":"### Gateway-forced login detection and validation simplified\n\nGateway login logic was simplified: looser URL validation and a more direct check for when login is forced through the gateway\n\n**Unclear.** the finding doesn't say what `Ao()` represents, so the exact condition that triggers the short-circuit isn't named\n\n**What**\n\n- The `forceLoginGatewayUrl` CLI option now accepts any non-empty string rather than requiring a syntactically valid URL.\n\n- The check for whether login is gateway-forced was simplified to: the login method is `\"gateway\"`, or a gateway URL is set \u2014 replacing a more convoluted prior condition.\n\n- The forced-login-method resolution for the login flow now short-circuits to `\"gateway\"` whenever the session is already in gateway auth mode, rather than only special-casing an explicit managed-setting value.\n\n- The gateway auth backend's API key check now short-circuits to reporting the key as \"missing\" first when in gateway mode without the expected check passing, instead of falling through to the normal API-key-helper\/environment-variable lookup.\n\n**Why** These changes make gateway-forced login detection more consistent and predictable across the CLI, reducing edge cases where login mode or API key status could be determined by a stricter or more roundabout check than intended.\n\n- Area: Auth\n- Names: `apiKeyHelper`\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5"}