CORS config not appearing Gitea Console Settings and not sure it is taking effect (FastAPI Swagger OAuth flow) #13157

New Issue

GiteaMirror · 2025-11-02T10:33:04-06:00

GiteaMirror commented

2025-11-02 10:33:04 -06:00

Originally created by @elapse2039 on GitHub (Jun 14, 2024).

Description

I have run into a CORS issue that I am maybe misunderstanding or misconfiguration.

What I'm wondering is which thing (the server or gitea) is complaining about CORS during the OAuth flow?

(Please note: I've replaced domain with mydomain.com)

I have...

create a FastAPI service with swagger docs and have "authorize" popup which expects Client ID and Secret that matches the Gitea Application I've setup.
I have a redirect URL in Gitea Application to https://myserver.mydomain.com/auth.
setup OAuth Authorization Code flow in a FastAPI hosted at myserver.mydomain.com.
added CORSMiddleware (Starlette or FastAPIs) to allow any cross-site origins under the mydomain.com
added CORS section to Gitea

In Swagger, I open the popup and when I authorize I get directed to Gitea website to login successfully but when coming back to the Swagger page, I see some flickering and this screenshot.

I see this in my browser console...

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gitea.mydomain.com/login/oauth/access_token. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gitea.mydomain.com/login/oauth/access_token. (Reason: CORS request did not succeed). Status code: (null).

(I dont get why there is a NS_ERROR_DOM_BAD_URI error.)

In fastapi project, I have included CORS

    origins = [
        "https://gitea.myserver.com",
    ]

    app.add_middleware(
        CORSMiddleware,
        allow_origins=origins,
        allow_credentials=True,
        allow_methods=["*"],
        allow_headers=["*"],
    )

In Gitea I've also tried enabling CORS... but I dont see this appear in the Gitea Console.

[cors]
ENABLED = true
ALLOW_DOMAIN = mydomain.com
ALLOW_SUBDOMAIN = true
ALLOW_CREDENTIALS = true
HEADERS = Content-Type,User-Agent                
METHODS = GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS

The OAuth flow is based on FastAPI docs and had some success integrating to Gitea OAuth Provider if I have explict APIs but not if I try and use Swagger UI which is what I'd really like to have working.

So my two questions:

Should I see CORS section in Gitea and how can I know it is actually working?
Which service is complaining about CORS? myserver.mydomain.com or gitea.mydomain.com?

Gitea Version

1.22

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

linux

How are you running Gitea?

Self hosted via docker compose.

Database

None

Originally created by @elapse2039 on GitHub (Jun 14, 2024). ### Description I have run into a CORS issue that I am maybe misunderstanding or misconfiguration. What I'm wondering is which thing (the server or gitea) is complaining about CORS during the OAuth flow? (Please note: I've replaced domain with mydomain.com) I have... * create a FastAPI service with swagger docs and have "authorize" popup which expects Client ID and Secret that matches the Gitea Application I've setup. * I have a redirect URL in Gitea Application to https://myserver.mydomain.com/auth. * setup OAuth Authorization Code flow in a FastAPI hosted at myserver.mydomain.com. * added CORSMiddleware (Starlette or FastAPIs) to allow any cross-site origins under the mydomain.com * added CORS section to Gitea In Swagger, I open the popup and when I authorize I get directed to Gitea website to login successfully but when coming back to the Swagger page, I see some flickering and this screenshot. ![ksnip_20240614-105544](https://github.com/go-gitea/gitea/assets/5325698/2f30f4cb-6ac2-476b-81a2-d83e921994ff) I see this in my browser console... ``` Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gitea.mydomain.com/login/oauth/access_token. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200 Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gitea.mydomain.com/login/oauth/access_token. (Reason: CORS request did not succeed). Status code: (null). ``` ![ksnip_20240614-110948](https://github.com/go-gitea/gitea/assets/5325698/11cf18fd-c863-4e81-ba27-f166da6bcc45) (I dont get why there is a NS_ERROR_DOM_BAD_URI error.) In fastapi project, I have included CORS ``` origins = [ "https://gitea.myserver.com", ] app.add_middleware( CORSMiddleware, allow_origins=origins, allow_credentials=True, allow_methods=["*"], allow_headers=["*"], ) ``` In Gitea I've also tried enabling CORS... but I dont see this appear in the Gitea Console. ``` [cors] ENABLED = true ALLOW_DOMAIN = mydomain.com ALLOW_SUBDOMAIN = true ALLOW_CREDENTIALS = true HEADERS = Content-Type,User-Agent METHODS = GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS ``` The OAuth flow is based on FastAPI docs and had some success integrating to Gitea OAuth Provider if I have explict APIs but not if I try and use Swagger UI which is what I'd really like to have working. So my two questions: 1. Should I see CORS section in Gitea and how can I know it is actually working? 2. Which service is complaining about CORS? myserver.mydomain.com or gitea.mydomain.com? ### Gitea Version 1.22 ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version _No response_ ### Operating System linux ### How are you running Gitea? Self hosted via docker compose. ### Database None

GiteaMirror added the issue/needs-feedback label 2025-11-02 10:33:04 -06:00

GiteaMirror closed this issue

2025-11-02 10:33:05 -06:00

GiteaMirror commented

2025-11-02 10:33:06 -06:00

@wxiaoguang commented on GitHub (Jun 14, 2024):

I ever worked on the CORS related code ( Refactor CORS handler #28587 ). IIRC the minimal config is:

[cors]
ENABLED = true
; or also comment the ALLOW_DOMAIN out:: list of requesting origins that are allowed, eg: "https://*.example.com", default to "*"
;ALLOW_DOMAIN = *

(unfortunately there is no easy way to check from console to see whether the config is correctly applied .... if the config file is right, it should work IMO)

@wxiaoguang commented on GitHub (Jun 14, 2024): I ever worked on the CORS related code ( Refactor CORS handler #28587 ). IIRC the minimal config is: ``` [cors] ENABLED = true ; or also comment the ALLOW_DOMAIN out:: list of requesting origins that are allowed, eg: "https://*.example.com", default to "*" ;ALLOW_DOMAIN = * ``` (unfortunately there is no easy way to check from console to see whether the config is correctly applied .... if the config file is right, it should work IMO)

GiteaMirror commented

2025-11-02 10:33:06 -06:00

@elapse2039 commented on GitHub (Jun 17, 2024):

Thanks for the clarification.

I am not seeing this make any difference.

One detail: The gitea server is behind an NGINX transparent proxy.

Possibly a solution....
I have found by adding a set of CORS headers that specify allowed origins for myserver.mydomain.com to the NGINX gitea proxy then myserver.mydomain.com can successfully make calls to gitea.mydomain.com.

Questions...

I am not sure if CORS headers are expected to traverse a NGINX proxy?

I havent tried placing Gitea service in front... but wondering if you would/should have CORS defined at NGINX or whether there is a problem with Gitea CORS?

@elapse2039 commented on GitHub (Jun 17, 2024): Thanks for the clarification. I am not seeing this make any difference. One detail: The gitea server is behind an NGINX transparent proxy. Possibly a solution.... I have found by adding a set of CORS headers that specify allowed origins for myserver.mydomain.com to the NGINX gitea proxy then myserver.mydomain.com can successfully make calls to gitea.mydomain.com. Questions... I am not sure if CORS headers are expected to traverse a NGINX proxy? I havent tried placing Gitea service in front... but wondering if you would/should have CORS defined at NGINX or whether there is a problem with Gitea CORS?

GiteaMirror commented

2025-11-02 10:33:06 -06:00

@wxiaoguang commented on GitHub (Jun 17, 2024):

Questions...

I am not sure if CORS headers are expected to traverse a NGINX proxy?

According to #28587 and related user feedbacks, I think Gitea should be able to handle CORS correctly. No idea why it doesn't respond correctly in your environment.

If the CORS is correctly enabled, you could see a startup log saying: CORS Service Enabled

@wxiaoguang commented on GitHub (Jun 17, 2024): > Questions... > > I am not sure if CORS headers are expected to traverse a NGINX proxy? According to #28587 and related user feedbacks, I think Gitea should be able to handle CORS correctly. No idea why it doesn't respond correctly in your environment. If the CORS is correctly enabled, you could see a startup log saying: `CORS Service Enabled`

GiteaMirror commented

2025-11-02 10:33:07 -06:00

@GiteaBot commented on GitHub (Jul 18, 2024):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Jul 18, 2024): We close issues that need feedback from the author if there were no new comments for a month. :tea:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#13157