-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Fix incorrect cookie path for AppSubURL #29534
Conversation
b455e3f
to
62f3232
Compare
How would this fix #29533? That BR mentions all the other links are fine, only pagination is broken because of a missing slash in it alone. Edit: The cookie thing might be one issue but I'm talking about the pagination being an issue. They need a slash, the link generation sections... |
|
See updated edit. The cookie thing might be a problem but I'm talking about another issue, |
I think there are 2 problems:
This PR's purpose is to fix the first one: make end users could use subpath correctly. For the second one, at the moment I didn't see a easy&clear fix for it. If the generated URLs don't affect daily use, I think we could have more time to do a big refactoring in the future to figure out how to handle the "$.Link" properly. Because the "Link" is just used this way widely, and "paginate.tmpl" is a general template used by many pages, not only for the home page (dashboard). |
Yes, there is an issue in the URL generation, the lack of a forward-slash and it appears to only affect the user dashboard itself at a quick glance. I checked the Instance in repo issues and those generate correct links. This appears isolated to the user dashboard. |
Gitea itself never adds trailing slash (update: to the full paths). If you see trailing slashes (in the full paths), are they added by your reverse proxy? |
We're not talking about a trailing forward-slash. Gitea adds the forward-slash after SUBPATH on everything else, just not pagination. They are not added by my proxy, it's Apache with no content-editing at all. Example:
That's in the actual source on every page (browser, view source). Only the dashboard's pagination is broken. Every other page appears fine and with a forward-slash correctly after SUBPATH. |
I see your point. The real problem is how Gitea uses the "SUBPATH". Gitea requires that "SUBPATH" doesn't have a trailing slash, because it is widely used like this: "{SUBPATH}/other-path". They are just hare-coded in many places, and not easy to change. The definition is: So at the moment, we can't simply change its definition or behavior. That's what I meant in #29534 (comment)
|
It does affect daily use but it's somewhat minor. Users simply can't go backward or forward in their dashboard history without editing the URL themselves. Edit: Perhaps the refactoring should simply have every link not add a forward-slash and have everyone end their SUBPATH in forward-slash (or append if missing). That might be the easiest way to refactor, but it's probably a major revision rather than minor given some parsers out there might need updating and such. |
Could you elaborate? What's wrong happens in this case if a user go backward or forward? By design: |
|
But for modern web servers, they never serve For the "cookie issue", that's what we are fixing now. According to MDN: it is right to use "/subpath" as cookie path, and that's what Gitea's old code did. After the fix, everything just works fine. |
They are different, one is a file and the other is a directory. Modern web servers respect that. I've double-checked it with an Ubuntu server running Apache. They've respected the differentiation since at least 2004. Edit: If there is no file called 'gitea' it will assume you meant to use the directory but the backend must be able to understand that (Gitea does, but not the cookie logic, that is what you found). Regardless, the issue of pagination is the only one I'm concerned with. |
I mean when you configure the "proxy pass" for Gitea, they never serve https://docs.gitea.com/administration/reverse-proxies#apache-httpd-with-a-sub-path |
Backport #29534 Regression of #24107 Co-authored-by: wxiaoguang <[email protected]>
Respectfully, I don't care what Gitea practices regarding files versus directories, that's a matter for RFC specs and I'm sticking to them for standards. Agreed it's off-topic, so I won't bother replying about it. |
* upstream/main: Breaking summary for template refactoring (go-gitea#29395) [skip ci] Updated translations via Crowdin Fix incorrect cookie path for AppSubURL (go-gitea#29534) gitea.service: Remove syslog.target (go-gitea#29550) Add option to set language in admin user view (go-gitea#28449) Fix elipsis button not working if the last commit loading is deferred (go-gitea#29544) Fix incorrect relative/absolute URL usages (go-gitea#29531) Add support for API blob upload of release attachments (go-gitea#29507) Fix queue worker incorrectly stopped when there are still more items in the queue (go-gitea#29532) remove util.OptionalBool and related functions (go-gitea#29513) Rename Action.GetDisplayName to GetActDisplayName (go-gitea#29540) Make PR form use toast to show error message (go-gitea#29545)
Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
Regression of #24107 : at that time, I was misled by the comment
Cookie path to store. Default is "/"
: because when AppSubURL is empty, the cookie path is not defaulted to "/". So I added a slash there. But when there is a sub path, the extra slash is wrong.