Having a ROOT_URL with a subdirectory breaks all kinds of things

[zilti]

• Gitea version (or commit ref): 1.6.0
• Git version: 2.14.3
• Operating system: NetBSD 8
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

When the ROOT_URL has a subdirectory, all kinds of things get messed up, namely: registration and login; the captcha; everything that involves creating, editing or deleting organizations, repositories and files in repositories because of the csrf tokens; and previewing edits.

Screenshots

[lafriks]

Strange, I'm running one instance in suburl and I don't seem to have problems. Could be reverse proxy configuration issue?

[zilti]

I'm using lighttpd with the following proxy config:

$HTTP["url"] =~ "^/gitea+" {
  proxy.server = ( "" =>
    (( "host" => "0.0.0.0", "port" => "3000" ))
  )
  proxy.header = ("map-urlpath" => (
    "/gitea" => ""
    )
  )
}

Everything else in gitea gets loaded fine. Only the actions mentioned above fail (and login redirects to example.com/gitea/gitea instead of example.com/gitea).

[zilti]

Oh, this seems to be a duplicate of the abandoned issue #5411.

[jabouchleih]

I cannot speak for lighttpd but Gitea with either NGINX or APACHE as a forward/reverse proxy works fine on an URL with a subpath, so that's definitely an issue with lighttpd.

[mckaygerhard]

it's not working due there's some hardcoded paths in the code to the domain event the configured subpath

this problems does not happened with gogs! and firts versions of gitea

[zilti]

Yes. When the configured ROOT_URL is e.g. https://example.com/gitea, the login form will redirect to https://example.com/gitea/gitea. Also the CSRF tokens will be generated for example.com/gitea/gitea URLs.

[mckaygerhard]

this bug are causing issues in others due root url are kind of hardcoded from ROOT_URL as i described in #5316 make it imposible cofigure it as subpath..

today it 1.6.2 release and the bug is still happened!

[lafriks]

I think the problem is how lighttpd handle proxying. Works just fine with Nginx, Apache and traefik

[mckaygerhard]

it happened in others.. too much tune up to handle it..

and if were the case, why it's not happened with gogs?

[mckaygerhard]

o yeah right! more easy are close issue rather than property support separate WORKING_DIR VS BINARY_DIR! Pufff

[zeripath]

@mckaygerhard Gitea has to know it's external address otherwise LFS cannot work. That is supplied using the ROOT_URL. Gitea works fine on a suburl on nginx and Apache - I know because that is how I run it. So there is something to do with the lighthttpd configuration above.

Now you're also mentioning a different problem with the WORKING_DIR and BINARY_DIR. I think I responded to that issue. Could you respond there?

[mckaygerhard]

@zeripath gitea was a fork of gogs.. quite xtrange that gogs already works and "now" gitea not! that resume perfectly all the things.. and there's no different problem.. i dont know too much around go lang but seems there's a serious problems with paths and roots web urls