CSRF Token expiration on PR review during several minutes after page is created

[sgabenov]

Description

Sometimes i face the issue, when starting review of PR i got error "Bad Request: invalid CSRF token". This happens when i try to post some comments to the PR. The web-page can be opened not more then for 20 minutes before i got this error.
As i understood from docs and other posts, CSRF token should be valid for more then 24hours before expiration and it is more, than user session exist. In my case the token expiration happens in less then 1 hour.

Gitea Version

1.20.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Git Version

No response

Operating System

No response

How are you running Gitea?

docker

Database

PostgreSQL

[wxiaoguang]

Are you using multiple accounts?

[sgabenov]

No, this is only from 1 user with 1 account.

[wxiaoguang]

It looks weird. I haven't got an idea for it. Could you help:

1. Check the web site URL you are visiting in your browser and the ROOT_URL in your "app.ini", what are they?
2. If you can replace the Gitea binary program (just copy a new binary to the docker's app directory and restart the docker container), I can help to add some more debug logs, then when this problem happens next time, we can have some more clues.

[sgabenov]

1. The URL in app.ini looks identical to the one used in browser
2. Where i can grab a modified binary?

[wxiaoguang]

The code is #26266 (you can also build it by yourself: GOOS=linux GOARCH=amd64 TAGS=bindata GITEA_VERSION="1.20-CsrfTest" make build).

The binary (for linux amd64 only, no sqlite support) is: https://github.com/wxiaoguang/gitea-test-release/releases/tag/v1.20-CsrfTest

You can docker cp ~/Download/gitea gitea:/app/gitea/gitea and restart (start/stop) the container (don't do compose up/down, it just resets the filesystem in the container)

Then you will see a startup log: [W] This is a special build for testing CSRF token issues

If the bad CSRF problem happens again, you will see some logs like:

[E] Failed to validate CSRF token "fR9m4zs0pzHbfsY07Ce-UOKhYkE6MTY5MDg4MTUxOTE1ODY4MDAwMA" (secret=!#..., id=1): CSRF token "fR9m4zs0pzHbfsY07Ce-UOKhYkE6MTY5MDg4MTUxOTE1ODY4MDAwMA" does not match expected value "fR9m4zstpzHbfsY07Ce-UOKhYkE6MTY5MDg4MTUxOTE1ODY4MDAwMA"
[E] CSRF in header: "", in cookie: "", in request: "fR9m4zs0pzHbfsY07Ce-UOKhYkE6MTY5MDg4MTUxOTE1ODY4MDAwMA"

[lunny]

Could you paste some of your configuration? ROOT_URL and which url are you visiting in your webbrowser?

[sgabenov]

Browser - https://gitea.devos.club/
Config:

[server]
APP_DATA_PATH = /data/gitea
SSH_DOMAIN = gitea.devos.club
ROOT_URL = https://gitea.devos.club
DISABLE_SSH = false
LFS_START_SERVER = true
DOMAIN = gitea.devos.club

[sgabenov]

I have figured out from the user with this problem, that he has a pined tab in his browser when he work with gitea. So, there is a pined tab and another tabs, where he do his work and where he got CSRF token problem. Could this pinned tab in browser be an issue?
We have a lot of developers in our gitea and such issue reports only 1 person.

[wxiaoguang]

So, there is a pined tab and another tabs,

Hmm, I also consider it as the key problem. The "pinned" tab might have been there for long time, the CSRF token in that tab might have been expired.

At the moment, there is no clear solution for this problem, but I think 1.21 (refactoring more forms to "form-fetch-action", like #25219) could avoid such problem as much as possible.

[wxiaoguang]

No more feedbacks. Feel free to provide more clues and some reproducible steps and reopen.