Sign in not possible behind tinyproxy with sub-path

[LauKr]

Description

Running Gitea behind a Reverse Proxy using a sub-path doesn't allow login.
This issue was first occurring with the update 1.21.10 -> 1.21.11 and
continues with 1.22.0.

After entering credentials and pressing the "Sign In" button, the
unauthenticated "root" site is shown again, like after a logout.

From the release notes
we noted the following change which seems suspicious:

Fix to delete the cookie when AppSubURL is non-empty (#30375) (#30468)

Therefore, we checked our configurations and ensured, they used trailing slashes:

$ grep -r "git-staging" /etc/gitea-staging /etc/tinyproxy/ 
/etc/gitea-staging/app.ini:ROOT_URL = https://192.168.1.12/git-staging/
/etc/tinyproxy/tinyproxy.conf:ReversePath "/git-staging/" "http://127.0.0.1:3333/"

The logs from our reverse proxy show a behavior as requested by the
documentation:

May 29 16:16:31 debian-git tinyproxy[390434]: Connect (file descriptor 5): 127.0.0.1
May 29 16:16:31 debian-git tinyproxy[390434]: Request (file descriptor 5): POST /git-staging/user/login HTTP/1.1
May 29 16:16:31 debian-git tinyproxy[390434]: Rewriting URL: /git-staging/user/login -> http://127.0.0.1:3333/user/login
May 29 16:16:31 debian-git tinyproxy[390434]: No upstream proxy for 127.0.0.1
May 29 16:16:31 debian-git tinyproxy[390434]: opensock: opening connection to 127.0.0.1:3333
May 29 16:16:31 debian-git tinyproxy[390434]: opensock: getaddrinfo returned for 127.0.0.1:3333
May 29 16:16:31 debian-git tinyproxy[390434]: Established connection to host "127.0.0.1" using file descriptor 6.
May 29 16:16:31 debian-git tinyproxy[390434]: Closed connection between local client (fd:5) and remote client (fd:6)
May 29 16:16:31 debian-git tinyproxy[390434]: Connect (file descriptor 5): 127.0.0.1
May 29 16:16:31 debian-git tinyproxy[390434]: Request (file descriptor 5): GET /git-staging/ HTTP/1.1
May 29 16:16:31 debian-git tinyproxy[390434]: Rewriting URL: /git-staging/ -> http://127.0.0.1:3333/
May 29 16:16:31 debian-git tinyproxy[390434]: No upstream proxy for 127.0.0.1
May 29 16:16:31 debian-git tinyproxy[390434]: opensock: opening connection to 127.0.0.1:3333
May 29 16:16:31 debian-git tinyproxy[390434]: opensock: getaddrinfo returned for 127.0.0.1:3333
May 29 16:16:31 debian-git tinyproxy[390434]: Established connection to host "127.0.0.1" using file descriptor 6.
May 29 16:16:31 debian-git tinyproxy[390434]: Closed connection between local client (fd:5) and remote client (fd:6)

We see the equivalent to

Make the reverse-proxy pass https://common.example.com/gitea/foo to http://gitea:3000/foo

Rewriting URL: /git-staging/user/login -> http://127.0.0.1:3333/user/login

The corresponding Gitea logs are:

May 29 16:53:07 debian-git gitea[390439]: 2024/05/29 16:53:07 ...eb/routing/logger.go:102:func1() [I] router: completed POST /user/login for 127.0.0.1:56322, 303 See Other in 68.6ms @ auth/auth.go:196(auth.SignInPost)
May 29 16:53:07 debian-git gitea[390439]: 2024/05/29 16:53:07 .../context_response.go:70:HTML() [D] Template: home
May 29 16:53:07 debian-git gitea[390439]: 2024/05/29 16:53:07 ...eb/routing/logger.go:102:func1() [I] router: completed GET / for 127.0.0.1:56324, 200 OK in 3.6ms @ web/home.go:32(web.Home)

Access logs in Gitea:

127.0.0.1 - - [29/May/2024:16:52:57 +0200] "GET /user/login HTTP/1.1" 200 10629 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"
127.0.0.1 - - [29/May/2024:16:53:00 +0200] "POST /user/login HTTP/1.1" 303 0 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"
127.0.0.1 - - [29/May/2024:16:53:00 +0200] "GET / HTTP/1.1" 200 14214 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"
127.0.0.1 - - [29/May/2024:16:53:02 +0200] "GET /user/login?redirect_to=%2fgit-staging%2f HTTP/1.1" 200 10629 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"
127.0.0.1 - - [29/May/2024:16:53:07 +0200] "POST /user/login HTTP/1.1" 303 0 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"
127.0.0.1 - - [29/May/2024:16:53:07 +0200] "GET / HTTP/1.1" 200 14214 "" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:126.0) Gecko/20100101 Firefox/126.0"

Resolving

After reverting commit b18c04e (and commenting
out two sections undefined afterwards, see patch), we are able to use the normal
login again, when using our custom built binary. Thus, this also shows that our
error is connected to this change.

Gitea Version

1.21.11 and 1.22.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.39.2

Operating System

Debian Bookworm

How are you running Gitea?

The binary is pulled from the official server. Execution is happening through systemd on Debian 6.1.85-1 (2024-04-11) 86_64.
The Gitea server is listening locally via HTTP and is served by a tinyproxy reverse proxy. TLS is terminated by stunnel in front of tinyproxy.

Database

SQLite

[wxiaoguang]

After reverting commit b18c04e, we are able to use the normal login again,
" fix: Fix to delete cookie when AppSubURL is non-empty #30375 "

@jtran would you like to take a look?

[wxiaoguang]

@LauKr could you help to elaborate some details?

1. Does the "login" work in a private window (without any existing cookie)?
2. If the login doesn't work, what are the cookies sent from server (Set-Cookie) and sent from client (Cookie)? Do they match?

[LauKr]

Sadly GitHub doesn't let me upload a file with .path extension. I changed it to .txt instead.
diff.txt

This diff shows the revert plus two comments that allowed us to login again.

[LauKr]

1. No, deleting cookies, using a private window etc. did not work. We already tried this first, due to [E] UserSignIn: not in 2FA session #29757 and AAD Login via OAuth fails with Dockerhub image "gitea/gitea"  #29881.
2. The POST request for login has the following cookies set:

   Set-Cookie: yummy_magical_cookie=/git-staging/; path=/
   Cookie: i_like_gitea=XXX; _csrf=XXX; yummy_magical_cookie=/git-staging/
   

[bohde]

I worked with @jtran on this change for bug we were seeing in a deployment that is also behind a reverse proxy (nginx in our case) with a subpath of /app_path/. The set-cookie headers as a result of POST /app_path/user/login look like the following in my Firefox network tab:

set-cookie i_like_gitea=; Path=/app_path/; Max-Age=0; HttpOnly; Secure; SameSite=Lax
set-cookie i_like_gitea=<redacted>; Path=/app_path; HttpOnly; Secure; SameSite=Lax
set-cookie lang=; Path=/app_path/; Max-Age=0; HttpOnly; Secure; SameSite=Lax
set-cookie_csrf=; Path=/app_path; Max-Age=0; HttpOnly; Secure; SameSite=Lax
set-cookie redirect_to=; Path=/app_path; Max-Age=0; HttpOnly; Secure; SameSite=Lax
set-cookie redirect_to=; Path=/app_path/; Max-Age=0; HttpOnly; Secure; SameSite=Lax

@LauKr based on my reading of your config, it appears like your cookies should set Path=/git-staging, but it appears that's not happening from the Set-Cookie header your posted.

[wxiaoguang]

@LauKr it doesn't seem right in your reverse proxy config.

Did you see any Set-Cookie for i_like_gitea? Which path is it on? It is directly related to Gitea login.

And, did you set any ReversePath or related config for your reverse proxy? I think they should be removed. UPDATE: maybe it should set ReverseMagic No, see below.

---

Since you are using tinyproxy, could you prepare a reproducible setup with detailed steps ? If you could provide a docker compose to reproduce, then I could try to debug it on my machine.

[wxiaoguang]

And one more thing, It seems that tinyproxy does some trick (black magic?) on the "cookie path". https://github.com/search?q=repo%3Atinyproxy%2Ftinyproxy%20REVERSE_COOKIE&type=code

I do not feel it is quite right. If there is a chance, I would recommend to try to use some modern and standard reverse proxies.

ps: I guess setting ReverseMagic No should resolve the problem, according to the code in tinyproxy:

[wxiaoguang]

Any update?

[LauKr]

Any update?

Sorry, I need some time for the reproducible build.

Changing ReverseMagic to No sadly didn't resolve the issue. I'll try debugging where the cookie went as soon as I find the time.

[LauKr]

Hi,
sorry for the delay. I wrote a Dockerfile to reproduce the issue. Necessary files are attached:
setup_for_debugging.tar.gz

Building and running was tested using Podman, but should work with Docker as well:

podman build -t gitea_proxy_testing --file Dockerfile
podman run --rm -it --publish 8888:8888 gitea_proxy_testing:latest

The Dockerfile creates a container with Gitea and tinyproxy. The tinyproxy is accessible via port 8888.
Accessing Gitea via 127.0.0.1:8888/git-staging/ was successful, but login was not possible, as described in the issue.