#17378: fix(gateway): allow dangerouslyDisableDeviceAuth with trusted-proxy auth mode

## Summary Fixes #8529 Control UI settings dangerouslyDisableDeviceAuth and allowInsecureAuth did not work when using trusted-proxy authentication. Previously, these options only applied to token or password authentication modes. This PR updates the authentication logic so that Control UI bypass settings are honored for authenticated trusted-proxy connections. ## Changes - Modified `src/gateway/server/ws-connection/message-handler.ts` to allow `allowControlUiBypass` to work with authenticated trusted-proxy connections - Added test case in `src/gateway/server.auth.e2e.test.ts` to verify the fix ## Root Cause In `message-handler.ts`, `canSkipDevice` only checked `sharedAuthOk` (which is only true for token/password auth), but didn't consider the `allowControlUiBypass` settings for trusted-proxy auth. **Before:** ```typescript const canSkipDevice = sharedAuthOk; ``` **After:** ```typescript const canSkipDevice = sharedAuthOk || (allowControlUiBypass && authOk); ``` ## Impact This allows Control UI to skip device pairing when: - dangerouslyDisableDeviceAuth is enabled, AND - The user is authenticated via trusted-proxy This is particularly useful for setups using identity-aware reverse proxies (nginx + oauth2-proxy, Pomerium, Caddy + OAuth, etc.) where device pairing adds unnecessary friction. ## Testing Added e2e test: allows control ui without device identity with trusted-proxy auth when device auth is disabled Configuration Example With this fix, the following configuration now works as expected: `Replace trustedProxies with your proxy IP` ````typescript { "gateway": { "bind": "lan", "trustedProxies": ["192.168.1.226"], "controlUi": { "dangerouslyDisableDeviceAuth": true }, "auth": { "mode": "trusted-proxy", "trustedProxy": { "userHeader": "x-forwarded-user" } } } } ```` <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes Control UI device authentication bypass for trusted-proxy auth mode. Previously, `dangerouslyDisableDeviceAuth` and `allowInsecureAuth` settings only applied to token/password authentication, leaving trusted-proxy users unable to skip device pairing despite explicit configuration. **Key changes:** - Updated `canSkipDevice` logic in `message-handler.ts:434` to honor `allowControlUiBypass` for any authenticated connection, not just shared-secret auth - Added e2e test verifying the fix works for `dangerouslyDisableDeviceAuth` with trusted-proxy auth The fix correctly checks that both `allowControlUiBypass` is enabled (meaning the user explicitly configured bypass settings) AND `authOk` is true (meaning the user is authenticated via trusted-proxy). <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with no risks identified - The fix is minimal, focused, and correct. It extends existing bypass logic to cover trusted-proxy auth without introducing security issues. The change maintains all security checks (still requires successful authentication and explicit bypass configuration), and adds appropriate test coverage. - No files require special attention _{Last reviewed commit: b8fc950} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->