Wrong redirection after add time to issue

[maherma-adg]

• Gitea version (or commit ref): 1.13.0 and previous
• Git version: 2.17.1
• Operating system: Linux - AMD binary from gitea site.
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No

Description

When I install gitea, I setup it on my local server (IP: 192.168.1.100) and it's working ok. But, I have configured a VPN when I'm roaming and I reach gitea server through a different IP (192.168.250.100).

VPN in Normal operation works OK, I can fetch/pull/push project without problem, and I can navigate and create/edit issues with the UI without problem.

The problem appear when I add time to an issue, after press approve button, I'm redirected to the issue page in the local IP not in the IP though VPN, this make to appear a 404 because I can't reach server through local IP.

The time added is registered and we go back and reload page to get the issue with time on screen.

Regards.
Manuel.

[noerw]

On AddTimeManually() action, Gitea will use the host specified in ROOT_URL config var for redirects, so there will only be one valid host.

We could make the redirect host-relative as in other post actions, like DisableTwoFactor().
A quick survey on the codebase shows this issue occurs in:

• routers/repo/issue_lock.go
• routers/repo/issue_watch.go
• routers/repo/issue_stopwatch.go
• routers/repo/issue_timetrack.go
• routers/repo/issue_dependency.go
• routers/repo/issue.go (NewComment())
• routers/user/setting/security_openid.go
• routers/user/auth_openid.go

[zeripath]

If you have two root_urls you're gonna find lots of other things don't work too.

I think therefore this issue is invalid and you should either retitle/rephrase or open another issue to ask for multiple rooturl support.

It would be possible to do something with this by looking at the remote IP of client connection or by listening on different ports - however the actual issue is one of configuration:

How do we come up with a concise reasonably uncomplicated and backwards compatible configuration to make this possible.

If an issue were written with such a proposed configuration, implementation wouldn't actually be too difficult.

Many feature requests on gitea would benefit from this additional level of thought.

[noerw]

I agree that issue title should be broader.

The configuration-less way to do it, is to switch to host-relative redirects. That's simple, and I already outlined above where this needs to be changed.

The more involved alternative is to treat this as a dupe of #8697 and #11732 (i.e. make things like repo.HTMLURL() consider the current request host), which I personally won't touch, as this is related to the macaron/chi refactor. (but could also be considered an opportunity to fix it while refactoring)

[maherma-adg]

I never though this will be a multi-root config related problem, as web developer I avoid any absolute reference as far as I can.
I agree with @noerw about host-relative redirects as solution, sadly i am not a go programmer so I can't help to fix them.

Please suggest me a new tittle for issue or I'll close it as dupe.

[zeripath]

OK we need to be clearer about what we mean when we say relative.

Usually "relative" in this case is actually an absolute path "/root-of-gitea/owner/reponame/..." rather than FQDN links. These absolute paths are still going to fail if you have Gitea mounted on a suburl on one IP/domain and on a different one on a different IP/Domain.

If you mean only ever emit truly relative addresses that's a lot of work and possibly not even possible. It would honestly be easier to allow the different mounting.

[wxiaoguang]

Related to

• Multi-domain support, ROOT_URL problem, use relative URLs in templates instead of absolute URLs #19345

Close this one