-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Closed
Labels
issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detailFor bugs, we need more details. For features, the feature must be described in more detail
Description
Gitea Version
1.15.6+27-gd29a0fc3b
Git Version
2.33.1
Operating System
Fedora 35 x64
How are you running Gitea?
Self-made RPM package, see https://gitlab.com/fhuberts/rpmsUpstream/-/tree/master/fedora/gitea
Database
PostgreSQL
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Description
Nov 28 14:57:07 git.somewhere gitea[3372]: 2021/11/28 14:57:07 Started POST /api/v1/repos/servers/server-installs/markdown for 192.168.180.11:0
Nov 28 14:57:07 git.somewhere gitea[3372]: 2021/11/28 14:57:07 Completed POST /api/v1/repos/servers/server-installs/markdown 403 Forbidden in 821.289µs
Screenshots
No response
Metadata
Metadata
Assignees
Labels
issue/needs-feedbackFor bugs, we need more details. For features, the feature must be described in more detailFor bugs, we need more details. For features, the feature must be described in more detail
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
fhuberts commentedon Nov 28, 2021
The same 403 is present in the apache webserver log.
I run gitea behind apache, on a unix domain socket.
[28/Nov/2021:15:18:04 +0100] "POST /git/api/v1/repos/servers/server-installs/markdown HTTP/1.1" 403 59 "-" "Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0"
wxiaoguang commentedon Nov 28, 2021
I just remembered another similar issue:
fhuberts commentedon Nov 28, 2021
This was also present on 1.14.
Just upgraded my server to 1.15 in the hopes that it would work now...
fhuberts commentedon Nov 28, 2021
I've tried changing the ROOT_URL as mentioned in the referenced issue, but that doesn't fix the problem.
fhuberts commentedon Nov 28, 2021
Setting the *_VISIBILITY variables to public also doesn't work.
Don't know what else to check now.
wxiaoguang commentedon Nov 29, 2021
Can you check (inspect) the requests sent by your browser? What's the difference between a correct request and an incorrect request?
fhuberts commentedon Nov 29, 2021
From the Firefox console.
Headers:
Request:
Must note that a different token appears to be sent than is stored in my cookies.
Also, Firefox reports 'CORS Missing Allow Origin' in the transferred column
for the request.
wxiaoguang commentedon Nov 29, 2021
Maybe that's the problem. On my side, the CSRF token in POST and in COOKIE are the same.
Can you check the source code of the page to see which CSRF token is correct? which is incorrect? The correct CSRF token should also exist in the page source code.
ps: You can safely paste the starting sub-string of your CSRF tokens here, it won't cause any security problem.
fhuberts commentedon Nov 29, 2021
The csrf is changed by the 403 response.
I checked after the response so that is why the token was different
zeripath commentedon Nov 29, 2021
What are your cookie settings in app.ini? It might just be helpful to paste that up entirely - skipping the secrets and the confidential stuff but explaining what the values are. (For example if your root URL is something like https://foo.example.com/bar put this in instead.)
Could you check if the problem still occurs in an incognito window?
Have you tried deleting all of your Gitea cookies?
fhuberts commentedon Nov 29, 2021
I have changed nothing in app.ini wrt cookies, everything is at defaults.
I've not set ROOT_URL.
Problem is present is private window as well.
Removing all cookies doesn't help.
fhuberts commentedon Nov 29, 2021
Even disabling selinux doesn't help, so it appears to be somewhere inside the application code
fhuberts commentedon Dec 2, 2021
This can easily be reproduced by setting up a Fedora 35 machine/VM and installing the RPM I created (see https://gitlab.com/fhuberts/rpmsUpstream/-/tree/master/fedora/gitea). I'll attach a built RPM package in a minute.
This should make it a lot easier to debug.
fhuberts commentedon Dec 2, 2021
Github refuses to attach the rpms/gz/zip. bummer.
It's quite easy to build the RPM yourself, or just ping me
20 remaining items
wolflu05 commentedon Jan 9, 2022
I saw that problem by another user using my gitea instance. First i wondered, why it doesn't render the wiki edit preview, because on my machine (using chrome) everything works fine. Maybe its due to the browser, because the other user was using edge.
zeripath commentedon Jan 9, 2022
OK so I've finally managed to start a fedora docker with systemd using https://hub.docker.com/r/jrei/systemd-fedora/
docker pull jrei/systemd-fedora docker run -d --name systemd-fedora --tmpfs /tmp --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:/sys/fs/cgroup:ro jrei/systemd-fedora docker exec -it systemd-fedora bash
Then in that container:
Now for whatever reason that postgres didn't come up for me straight away, but I think the db is irrelevant so I switched to sqlite by editing the app.ini and restarted gitea:
vi /etc/gitea/app.ini # to edit the app.ini as above systemctl restart gitea
Then on the host I navigate to:
created a user and then a test repository.
Then gone to wiki markdown and yes I can reproduce the issue, but looking in the network console I see:
POST https://8eba9d421607/git/api/v1/repos/administrator/simple-test/markdown
Now I remember I've not set a ROOT_URL in app.ini ... (Gitea requires that you set the ROOT_URL to match the site.)
So now I go back to command line and change the app.ini using
vi /etc/gitea/app.ini
:then I run
And refresh my edit page.
et voila ça marche.
fhuberts commentedon Jan 9, 2022
I tried both Firefox and Chrome. Both show the same result.
fhuberts commentedon Jan 9, 2022
@zeripath
If you use the RPM then the ROOT_URL will have been setup already, on my server it shows like:
DOMAIN = hostname.domain.name
ROOT_URL = https://%(DOMAIN)s/git/
Thanks for looking into this, it helped me narrow down the problem...
I made it work on my server, and the problem is that I need to access the server with its FQDN to make it work!
This seems very weird and actually a bug.
More so because for the preview of an issue comment there is no such requirement, that works fine for both the FQDN and its simple hostname.
Literally the only thing different is using the 'hostname.domain.name' or 'hostname'.
And the POST goes out to the same (apart from the FQDN) URL.
The POST are the same.
fhuberts commentedon Jan 9, 2022
Setting domain to 'hostname' has the following effect:
Same/reverse holds when setting domain to 'hostname.domain.name'.
(I did see it work for issue comment previews a few times but can't reproduce that now)
Seems like a hostname check is too strict.
fhuberts commentedon Jan 9, 2022
For now I've implemented a workaround for this bug (see https://gitlab.com/fhuberts/rpmsUpstream/-/commit/d403b45ede235a1852e57be9546b169b44fdcbe3?w=1).
zeripath commentedon Jan 9, 2022
It would be useful if you could check the cookies that are set. You'll probably find that the cookies are being set as per the FQDN or hostname as appropriate.
https://stackoverflow.com/questions/1062963/how-do-browser-cookie-domains-work
fhuberts commentedon Jan 9, 2022
Without the workaround cookies are stored under 'hostname', with the workaround cookies are stored under 'domain.name'.
fhuberts commentedon Jan 9, 2022
I also just discovered why issue comment previews sometimes seem to work: in a list with issues, the links to the issues (on the issue titles) are to the FQDN of the issue, even though the page with the list is opened on the 'hostname'!
fhuberts commentedon Jan 10, 2022
Summary:
Previews only work when the server is accessed through its full hostname (FQDN).
wxiaoguang commentedon Jan 10, 2022
Currently, Gitea uses an absolute full URL
<a class="preview item" data-url="{{$.Repository.APIURL}}/markdown" data-context="{{$.RepoLink}}">{{$.i18n.Tr "preview"}}</a>
to do preview. The absolute full URL is generated byROOT_URL
, it must match the FQDN you are visiting.That's why we asked many times to check whether the CSRF token and COOKIE were working correctly.
wxiaoguang commentedon Apr 12, 2022
After many refactoring to the URL and CSRF modules, this issue can be closed
And a new issue for the root problem: