Skip to content

fix(urls): keep the port when building public URLs - #1177

Open
rawdaymx wants to merge 1 commit into
ChatbotXIO:mainfrom
rawdaymx:fix/public-url-port
Open

rawdaymx wants to merge 1 commit into
ChatbotXIO:mainfrom
rawdaymx:fix/public-url-port

Conversation

@rawdaymx

Copy link
Copy Markdown
Contributor

Fixes #1152.

Assigning the public host to a URL and then clearing .port drops any non-default port, so :3123 (or whatever port a self-hosted deployment uses) disappears from OAuth redirect_uri values and from auth redirects. The operator is sent to a URL that does not resolve.

The same pattern was in three places, not the two named in the issue. auth-redirect.ts:70 has it too; we found it while writing the report, and it is included here.

Verification

  • packages/utils: 8/8 passing
  • apps/builder: 4/4 passing
  • ultracite check clean on all five files

And the assertions are not decorative. Reverting only the three source files while keeping the new tests turns 2 of 8 and 2 of 4 red — so the coverage tracks the fix rather than accompanying it.

Assigning the public host to a `URL` and then clearing `.port` drops any
non-default port, so `:3123` disappears from OAuth `redirect_uri` values and
from auth redirects. Self-hosted deployments that do not sit on 80/443 get
redirected to a URL that does not resolve.

The same pattern was in three places, not two: `proxy.ts`, `request.ts` and
`auth-redirect.ts:70`.

Tests: the two existing suites keep passing (8/8 in `packages/utils`, 4/4 in
`apps/builder`), and reverting only the three source files while keeping the
new assertions turns 2 of 8 and 2 of 4 red — so the coverage is real.

Fixes ChatbotXIO#1152
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working as expected

Projects

None yet

1 participant