{"version":"2.1.268","anchor":"gateway-setup-screen-gains-an-internalnetworks-prop","canonical_anchor":"gateway-device-code-login-can-verify-the-connection-stays-in","heading":"Gateway login can recognize and display internal network paths","tier":"notice","area":"Gateway","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/gateway-setup-screen-gains-an-internalnetworks-prop","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Gateway login can recognize and display internal network paths\n\nDevice-code gateway login now checks whether the connection stays inside a declared internal network and shows the path in the trust prompt.\n\n**Unclear.** What internalNetworks controls in the gateway setup flow is not specified by the finding.\n\n**What**\n\n- The interactive gateway login flow (the device-code OAuth sign-in) now accepts a list of declared internal networks (`internalNetworks`) and resolves the gateway's host against that list before contacting the OAuth endpoint.\n\n- If the connection matches a declared network, the trust prompt shown to you now displays the actual network path, e.g. \"Connecting from to , both inside declared \".\n\n- The gateway setup screen component was updated to accept this `internalNetworks` list as a new prop alongside the existing `initialUrl` and `screenLocked` props, so the wizard can be told about or restricted to these internal addresses.\n\n**Why** Seeing the concrete network path in the trust prompt makes it easier to verify a gateway connection is staying inside your organization's declared network rather than silently trusting an unfamiliar route.\n\n- Area: Gateway\n- Names: `internalNetworks`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 3\/5"}