Let Gitea answer Decap's cross-origin token request

Decap is served from vienalatina.com and posts its OAuth code to
git.vienalatina.com/login/oauth/access_token from the browser. Gitea disables
CORS by default, so the browser discarded the response and Decap surfaced it
as "TypeError: Failed to fetch" after a successful authorize — the login looks
broken at the last step, with nothing wrong on either side individually.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
This commit is contained in:
Claude 2026-09-18 14:17:44 +00:00
parent 6890ff4153
commit b69e9d6f81
No known key found for this signature in database

View File

@ -14,6 +14,15 @@ services:
- GITEA__server__SSH_DOMAIN=git.vienalatina.com - GITEA__server__SSH_DOMAIN=git.vienalatina.com
- GITEA__service__DISABLE_REGISTRATION=true - GITEA__service__DISABLE_REGISTRATION=true
- GITEA__webhook__ALLOWED_HOST_LIST=ci.vienalatina.com - GITEA__webhook__ALLOWED_HOST_LIST=ci.vienalatina.com
# Decap is served from vienalatina.com but exchanges its OAuth code for a
# token by calling git.vienalatina.com from the browser — a cross-origin
# request. Without this, Gitea returns no Access-Control-Allow-Origin, the
# browser drops the response, and Decap reports "TypeError: Failed to
# fetch" right after you authorize, which reads like a Decap bug.
- GITEA__cors__ENABLED=true
- GITEA__cors__ALLOW_DOMAIN=https://vienalatina.com
- GITEA__cors__METHODS=GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS
- GITEA__cors__HEADERS=Content-Type,User-Agent,Authorization
volumes: volumes:
- ./data:/data - ./data:/data
- /etc/timezone:/etc/timezone:ro - /etc/timezone:/etc/timezone:ro