Gitea: UI Breaks with Nginx proxy_pass

[methodbox]

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

Description

Using a basic proxy_pass in Nginx breaks asset paths instantly. Fresh install with proxy_pass URL specified doesn't work.

Updating app.ini doesn't work

Proxy pass settings:

location / {
        proxy_pass http://[ip address]:3000;
        proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;

        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }

App works without Nginx on 3000, but that's kind of useless. I'm afraid it will break using a valid domain name.

Screenshots

[niclashoyer]

This is the location block that I use:

        location / {
                proxy_pass http://unix:/var/run/gitea/gitea.sock;
                proxy_set_header Host $host;
        }

don't know if the try_files is actually necessary?

[jonasfranz]

Please checkout our guide for using reverse proxies: https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy

Do the problems occur still after following our guide?

[lunny]

@niclashoyer maybe you can also contribute to https://docs.gitea.io/en-us/reverse-proxies/#using-nginx-as-a-reverse-proxy when using unixsock protocols.

[methodbox]

My config is very much the same but I did not specify the server name and you might be right about the try methods; they’re in their by default and I’ve only ever had to add to them.

I’ll give this a try later.

Did not realize you had a special guide but to be honest I’ve never had to use special configuration for proxying a given web app from its port to port 80.

I build Nodejs apps and haven’t experienced this problem, but not familiar with Go enough to understand if it’s somehow different.

[jonasfranz]

@methodbox You could also set the port of gitea to 80 or 433 (if you prefer https) but this may require root.

[techknowlogick]

Here is a sample configuration that @thehowl posted to our Forum: https://discourse.gitea.io/t/call-gitea-as-a-subdomain-of-nginx/266/2

[methodbox]

@JonasFranzDEV That’s a terrible recommendation from a security standpoint.

Your application should never also be it’s own web server, let alone be allowed to handle HTTPS transactions.

This coupled with the idea that you suggested root being the owner of the process makes me question the technical knowledge behind this project.

I appreciate that you may be a qualified Go developer but your grasp of server administration may be lacking if you’d even consider that response as one to be taken seriously.

[jonasfranz]

@methodbox I don't see your point why a reverse proxy with no additional configuration should make a web application more secure. The only advantage might be that you could hide your gitea instance from the public. In addition you so called web server will be started also as root because no process could use a port <1024 without root permissions. I don not recommend running gitea as root but you could use other solutions like running gitea via docker which might be easier for not experienced user.

This project comes to you for free and the support many users are giving to you are also free.

[techknowlogick]

To bind to a port below 1024, you can use setcap on Linux: sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea.

[methodbox]

The reverse proxy is only part of the few steps to add additional security but an application should never run as its own web server, if nothing else.

Nginx is definitely going to be able to handle more requests than the Go service daemon, for example.

There’s also the benefit of something that can manage all kinds of different insecure header requests, block POST requests by default and the list goes on.

Your app server should never be your web server. There’s plenty of info out there in the Nodejs world that you can google if you want to learn more.

Here’s the first Reddit thread I found in a lazy google which has plenty of good reasons: https://www.reddit.com/r/node/comments/6b3voh/why_would_you_use_a_reverse_proxy_for_node/

That said, I missed a step in my Nginx server block - server_name - which seems to have resolved the issue.

[MiguelNdeCarvalho]

Hey, I am having the same issue. Can you guys help me?

[techknowlogick]

@MiguelNdeCarvalho perhaps this page could help you: https://docs.gitea.io/en-us/reverse-proxies/