Https communication in gitea

Support apps
,
1

What app is this about, and its version: 1.26.1~ynh1
What YunoHost version are you running: 13.0.4
What type of hardware are you using: VPS bought online

Describe your issue

Hi everybody,

I’ve been playing with my yunohost install for some time, so far so good !
After trying to effectively use the instance for git projects, I came across an issue with gitea https communication that I am not able to correct after a few attempts.

My issue is very close to the one described in this thread :

But attempting to modify the yunohost configuration like described in the thread (which is change the value of protect_against_basic_auth_spoofing for the gitea application) did not resolve my issue, so I’m kind of stuck on this right now.

I did the classic checks of things on yunohost configuration, which is :

  • make sure users have the gitea permission
  • make sure visitors also have the gitea permission (without this, git was redirected on yunohost sso page, now it’s fixed)
  • make sure gitea is hosted on a subdomain instead of a suburl (I had trouble authenticating with git when I was using a suburl, now it’s working correctly)

So now, onto the steps where I get an authentication issue; I installed both git-credential-manager and git-credential-oauth to help with auhtentication. I found that gitea does have a prebuilt configuration for these two solutions, and the configuration is active by default in the yunohost installation.

Basic step then, I’m running the command :
git clone https://gitea.<mydomain>.<com>/<projectfolder>/<project>.git
The URL is a direct copy/paste of the URL provided by gitea when browsing the depot and aksing for the clone informations

At that point, I’m able to encounter 2 scenarios :

  • the command line asks me for user / password information
  • a web page pops up, and gitea asks me if I want to allow access to repository; this is the oauth token authentication that should also work I guess

Both paths seems happy with the authentication, but always ends up with the following message : remote: Unauthorized fatal: Authentication failed for https://gitea.<mydomain>.<com>/<projectfolder>/<project>.git

So I’m stuck on this path; I tried an alternative way of cloning the project through ssh, with public / private key authentication through gitea.

That works ! So I’m happy with the result, and it’s even a way I would prefer to use over the https cloning method.
But things got back to an authentication issue because I wanted to use the lfs features provided by gitea on git projects, and lfs goes through http calls to provide the functionalities on top of git.

When trying to push changes on git, the lfs part starts its part and tell me that there is an authentication issue; sorry I don’t have this setup working anymore, but I know I tried a few things, even injecting login / password information in the git origin url (which is ugly), and the result I got was a 401 error on a POST operation, with an error message looking like : ERROR: Authentication error: Authentication required: You must have push access to verify locks

At this point, my guess is that the issue I encounter is similar in both paths I tried, and maybe there is a security or a check on yunohost side that prevents the authentication to succeed. Which points back to the thread I found that disables auth spoofing protection, but that didn’t solve my problem.

Anyone has a clue on what could cause the authentication issues I encountered ?
I also read on the forums that some people tweaked a variable called “ENABLE_REVERSE_PROXY_AUTHENTICATION” in the configuration of gitea, and while browsing the config file there is a comment that says that variable is set to false until the following issue is merged :

That goes beyond what I know of how things work, but could this be linked ?

Thanks for the help :slight_smile:

Share relevant logs or error messages

Update : after investigating the logs of nginx, I can see the following calls happening on the subdomain of git ; the application asks for an access token, then does a login and gets a 200 response, meaning token auth succeeded. After that, a get operation happens but gets rejected with a 401 code

2a01:e0a:105c:8e20:76e0:6d85:7ab1:bcd9 - punky [07/Jun/2026:11:58:03 +0000] "POST /login/oauth/grant HTTP/2.0" 303 0 "https://xxx.xxx.xxx/login/oauth/authorize?response_type=code&client_id=e90ee53c-94e2-48ac-9358-a874fb9e0662&state=4d8034cae7cc41c1baffa423bb9d0e81&code_challenge_method=S256&code_challenge=ANDE2xWY05zj5vQ3hRCcEkfhAYOQkrrV8H57vxvGf4I&redirect_uri=http%3a%2f%2f127.0.0.1%3a33677%2f" "Mozilla/5.0 (X11; Linux x86_64; rv:151.0) Gecko/20100101 Firefox/151.0"
2a01:e0a:105c:8e20:76e0:6d85:7ab1:bcd9 - - [07/Jun/2026:11:58:04 +0000] "POST /login/oauth/access_token HTTP/1.1" 200 1796 "-" "Git-Credential-Manager/2.8.0.0 (Linux; x86-64) CLR/.NET 10.0.7"
2a01:e0a:105c:8e20:76e0:6d85:7ab1:bcd9 - OAUTH_USER [07/Jun/2026:11:58:04 +0000] "GET /xxx/xxx.git/info/refs?service=git-upload-pack HTTP/2.0" 401 13 "-" "git/2.54.0"
2

Ok I found a sort of solution for my problem; turns out there is an other app called forgejo that is packaged for yunohost and is a fork of gitea. This should provide similar functionalities, and there is an interesting information in the documentation of the yunohost packaged version :

Git command access with HTTPS

If you want to use the Git command (like git clone, git pull, git push), you need to set this app as public.

Turns out that setting the app as public means that on the api of the app, permission should be added for “all_users”.

And with that, cloning the depot through https worked right of the box after the authentication step through user / password. Pushing lfs elements also succeeded, so I’m happy with the results !

If that can help anyone,