-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sign in not possible behind tinyproxy with sub-path #31202
Comments
@LauKr could you help to elaborate some details?
|
Sadly GitHub doesn't let me upload a file with .path extension. I changed it to .txt instead. This diff shows the revert plus two comments that allowed us to login again. |
|
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
@LauKr based on my reading of your config, it appears like your cookies should set |
@LauKr it doesn't seem right in your reverse proxy config. Did you see any And, did you set any 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. |
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 |
Any update? |
Sorry, I need some time for the reproducible build. Changing |
Hi, 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. |
I guess the problem is caused by that the new cookie is correctly removed by the "deleting legacy code". So I think we could try to flip the order: first delete the legacy cookie, then set new cookie, then the new cookie won't be deleted. -> Delete legacy cookie before setting new cookie #31306 |
Wait for backport to 1.22 |
When trying use a custom build on commit 5342a61, the problem was not fixed in the provided container setup. |
Backport merged, wait for @LauKr 's confirmation and feedback. |
It's said that the "fix" doesn't work. |
I think it is a bug in tinyproxy. By using Gitea tells tinyproxy:
Tinyproxy tells browsers
Tinyproxy loses most cookies for browsers. |
I would suggest to use a professional reverse proxy like nginx, which is also small enough and I guess it won't cost more resources than tinyproxy. |
Thanks for the effort. |
For reference, if anyone happens to have the same issue:
The corresponding PR is still open: tinyproxy/tinyproxy#435 However, we were able to confirm the fix by building a custom version of Using this custom version of @wxiaoguang from my side this issue can be closed, as this is evidently no Gitea issue. |
Thank you very much for the details! |
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:
Therefore, we checked our configurations and ensured, they used trailing slashes:
The logs from our reverse proxy show a behavior as requested by the
documentation:
We see the equivalent to
The corresponding Gitea logs are:
Access logs in Gitea:
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
The text was updated successfully, but these errors were encountered: