fix(#46, #59): handle CORS in Gitea instead of a traefik middleware #68

2026-09-21T08:37:07Z

cgalo5758 commented

2026-09-21 08:37:07 +00:00

First-time contributor

Moves CORS from the traefik middleware to Gitea's own [cors] section.

The traefik _cors labels don't work here:

compose.yml hardcodes https://${GITEA_CORS_ALLOW_DOMAIN}, so only one origin is possible. Comma- and space-separated values both fail. 3wc and I hit this in April 2025 with recipes.coopcloud.tech + wiki.cafe on git.coopcloud.tech.
The middleware only allows GET/OPTIONS/PUT. Decap's OAuth token exchange and its commits are POSTs, so they fail preflight. That's the "Failed to fetch" right after authorization in #59.
It stacks on top of whatever Gitea sends itself, which is the duplicate headers in #46.

GITEA__cors__* env vars can't fix it: app.ini is a docker config rendered from app.ini.tmpl and mounted read-only, and the recipe replaces docker-setup.sh, so the image's env-to-ini step never runs.

Changes: render [cors] when GITEA_CORS_ALLOW_DOMAIN is set, drop the _cors labels from compose.yml and compose.anubis.yml, bump APP_INI_VERSION to v24, document the variable in .env.sample and README.

Breaking: the value now needs the scheme, comma-separated for multiple, e.g. GITEA_CORS_ALLOW_DOMAIN=https://recipes.coopcloud.tech,https://wiki.cafe. Gitea's ALLOW_DOMAIN is an origin list, so entries have to be full origins.

Tested the template with the variable set and unset (block toggles), and checked 1.27.3: with [cors] on, the API router allows Authorization plus the full method set, and /login/oauth/access_token answers its own OPTIONS.

forgejo has the same labels; separate PR once this lands.

Moves CORS from the traefik middleware to Gitea's own `[cors]` section. The traefik `_cors` labels don't work here: - compose.yml hardcodes `https://${GITEA_CORS_ALLOW_DOMAIN}`, so only one origin is possible. Comma- and space-separated values both fail. 3wc and I hit this in April 2025 with recipes.coopcloud.tech + wiki.cafe on git.coopcloud.tech. - The middleware only allows GET/OPTIONS/PUT. Decap's OAuth token exchange and its commits are POSTs, so they fail preflight. That's the "Failed to fetch" right after authorization in #59. - It stacks on top of whatever Gitea sends itself, which is the duplicate headers in #46. `GITEA__cors__*` env vars can't fix it: app.ini is a docker config rendered from app.ini.tmpl and mounted read-only, and the recipe replaces docker-setup.sh, so the image's env-to-ini step never runs. Changes: render `[cors]` when `GITEA_CORS_ALLOW_DOMAIN` is set, drop the `_cors` labels from compose.yml and compose.anubis.yml, bump APP_INI_VERSION to v24, document the variable in .env.sample and README. Breaking: the value now needs the scheme, comma-separated for multiple, e.g. `GITEA_CORS_ALLOW_DOMAIN=https://recipes.coopcloud.tech,https://wiki.cafe`. Gitea's ALLOW_DOMAIN is an origin list, so entries have to be full origins. Tested the template with the variable set and unset (block toggles), and checked 1.27.3: with `[cors]` on, the [API router](https://github.com/go-gitea/gitea/blob/v1.27.3/routers/api/v1/api.go#L948-L956) allows `Authorization` plus the full method set, and [`/login/oauth/access_token`](https://github.com/go-gitea/gitea/blob/v1.27.3/routers/web/web.go#L615) answers its own OPTIONS. forgejo has the same labels; separate PR once this lands.

cgalo5758 added 1 commit 2026-09-21 08:37:07 +00:00

fix(#46 , #59 ): handle CORS in Gitea instead of a traefik middleware f44abdbfcf

cgalo5758 referenced this pull request

2026-09-21 08:42:51 +00:00

Cannot enable CORS in config #59

cgalo5758 referenced this pull request

2026-09-21 08:48:22 +00:00

conflicting headers #46

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions