officerdev/platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

gitea: correct which endpoint mints which origin

Browse Source 
The previous commit's explanation of retargetUrls was inverted, in the message and in the comment.
It said /user and /repos build from ROOT_URL and /contents from the public host. It is the other
way round: this instance's app.ini has ROOT_URL = https://gitea.pastilhas.dev/, which is what
/contents stamps, while /user and /repos echo the REQUEST host — loopback, because Officer dials
http://localhost:9004 directly instead of going through the reverse proxy.

Behaviour is unchanged and was already right: rewrite only a private/loopback URL, only onto a
public target. Which half of the response is wrong does not affect that rule, which is why the bug
did not show up in testing. But a comment that names the wrong cause is how the next change
re-breaks it, so this corrects the record.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
pastilhas
2026-08-06 17:19:32 +00:00
co-authored by Claude Opus 5
parent 10ff23c5dd
commit 1e3b64c6c2
1 changed files with 9 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/workspaces/officerdev/src/apps/Gitea/shared.ts
+9 -5
View File
@@ -420,11 +420,15 @@ export function isUnreachableFromBrowser(host: string): boolean {
* Rebase instance-minted URLs onto `origin`, IN ONE DIRECTION ONLY: a URL the browser cannot reach is moved
* onto one it can, never the reverse.
*
* The direction matters because this instance answers with two different origins — `/user` and `/repos`
* build from its configured ROOT_URL (`http://localhost:9004`), `/contents` from the public host
* (`https://gitea.pastilhas.dev`). An unconditional rewrite onto the connection URL therefore *broke* the
* second set to match the first, turning working https links into dead loopback ones and tripping mixed
* content on the way. Verified against the live instance on 2026-08-06.
* The direction matters because an instance can answer with two different origins at once, and the one
* matching the connection URL is not necessarily the good one. Gitea stamps most URLs from its own
* configured `ROOT_URL` — the public address — but some endpoints echo the REQUEST host instead, and
* Officer dials the instance directly rather than through its reverse proxy. So dialling
* `http://localhost:9004` an instance whose `ROOT_URL` is `https://gitea.pastilhas.dev` yields
* `/contents` on the public host and `/user`, `/repos` on loopback. An unconditional rewrite onto the
* connection URL therefore *broke* the good half to match the bad, turning working https links into dead
* loopback ones and tripping mixed content on the way. Verified against the live instance and its
* `app.ini` on 2026-08-06.
*
* So: only a private/loopback URL is rewritten, and only when `origin` is itself publicly reachable. When
* the connection URL is a dial address there is nothing better to offer, and the correct move is to change