Gitea: Using Gitea with domain forwarding

[GelLiNN]

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

Description

I am running a subdomain from my godaddy domain buildingintellect.com and my intent is to have my gitea server (which runs at http://buildintel.webhop.biz:48502) to be forwarded to code.buildingintellect.com.

Trying to do this out of the box like my other sites which I have running on other subdomains of buildingintellect.com gives me a sameorigin iframe error in the browser console.

This error is included in the screenshot. I'm wondering if there is a way to set the XFRAME-OPTIONS header like I have done from my other subdomain sites, maybe with a configuration option or something. This could specify the exact client domain that would allow iframe loading to minimize security risks as well.
...

Screenshots

[coolaj86]

This sounds like a workaround to a workaround. What's the original problem? What is the reason that you're doing the iframing in the first place?

Perhaps there's a better way to accomplish your same root goal in a less hacky way.

I'm going to take a wild guess and say that you're trying to use a raspberry pi from your closet (or similar) and don't have "real" ports available so you're having it run through free dyndns because you don't want to spend the cash on Digital Ocean.

You might look into Telebit (a service I run) or FreeDNS.

[GelLiNN]

Alright man, before you start making all these assumptions about my infrastructure I've developed, let me clear some things up for you.

First of all, I have no choice about the iframe. I agree with you that ideally you wouldn't want to run gitea inside one, but sadly with godaddy domain forwarding thats the solution approach the developers at godaddy went with. So my workaround for other websites I run has been to allow certain specified domains to have the xframe options header allow the site to load.

With gitea Im simply unsure how to change any of the site-wide header configuration. Thats the reason for my question. If there is another way for me to run gitea using this domain Ive purchased from godaddy, Im all ears to solutions.

My web server is has 32gb of ram and runs on-prem for my small business and thats why the DNS is set up the way it is as opposed to common cloud hosting. The site simply runs at buildintel.webhop.biz:48502 and my subdomain code.buildingintellect.com needs to forward to that site with masking.

[coolaj86]

Why the thumbs down? I wasn't trying to be insulting by saying you might be running an RPi in a closet, that's a pretty common use case (and it wasn't that far off - on-prem is on-prem).

Why not just open the port on your firewall and set the DNS servers for code.buildingintellect.com to your business IP address? And if your business IP address is dynamic, why not use FreeDNS or DynDNS and point the domain NS records to that?

As for adding the iFrame headers: Gitea isn't intended to be used as a full webserver. I'd recommend checking out Caddy or nginx.

I'm just a community member, not a maintainer, so I don't have much say in the matter, but I would be opposed to adding generic webserver functions into Gitea. I would be pro providing bundled installers or documentation on how to use a real webserver to do webserver-y things with Gitea.

[techknowlogick]

Closing this as an implementation question. Suggestions from @coolaj86 are suitable (if you need to modify headers then caddy or nginx are better than gitea for that)

If you wish to discuss more on this topic please open a thread on the forum: https://discourse.gitea.io/

[coolaj86]

I happened to come across this: https://github.com/go-gitea/gitea/blob/master/modules/context/context.go#L257

I believe most proxies can be configured to overwrite response headers but, as it turns out, we are setting X-Frame-Options: SAMEORIGIN explicitly.

IIRC the security benefit to this is that it can prevent clickjacking, which may be why we turn it on by default.

Perhaps we should make it configurable. I don't have a strong opinion on it at the moment.

[GelLiNN]

Thanks coolaj86. I have found a workaround for this by reverse-proxying to gitea through an Apache VirtualHost. Inside my VirtualHost I should be able to add configuration in the form of directives to replace ingoing and outgoing headers:
https://httpd.apache.org/docs/current/mod/mod_headers.html

Thanks for the tips here everyone!