Skip to content
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

nginx_proxy: Support extra user-defined network ports and http block configuration #3406

Closed
wants to merge 2 commits into from

Conversation

BlackHoleFox
Copy link

So in summary, the commits here provide two new features in the NGINX proxy:

  1. Add 5 customizable ports that can used to bind extra servers within the existing share/nginx_proxy/ customization.
  2. Add a new customization file that allows users to put statements inside the default http block

My use case is making a specific server to re-serve a home assistant integration's URLs in a more protected manner. By having a dedicated server block and port, I can be sure no unintended locations are reachable from it and also apply more external firewall rules with the added separation.

As far as I can tell, there's no way to dynamically apply a container:host port mapping to an addon, so multiple unused and default-off mappings were added to allow a reasonable amount of flexibility for users going onward.

I'd also like to apply rate limiting to custom NGINX server blocks, which needs a limit_req_zone statement inside of the top-level http context to work in order to work.

Both commits tested in my local HAOS deployment and seems to work fine.

UI Examples

image image

Considered Alternatives

  • Use the same domain and port by putting new config data in /share/nginx_proxy_default*.conf? In my use case, there's no way to then stop the location / block from running if my new location doesn't match, which is a problem.
  • Use a different domain and listen on 443 as well? SNI-based routing makes this a non-starter.
  • Use the existing tcp/80 mapping with your own external port? Using this port results in TLS errors because it attempts to redirect HTTPS traffic to a HTTP listener.
  • Fork the addon long term? This is a hassle to maintain and keep up to date with the upstream source here, and I'm sure there's someone else who has wanted functionality like this.....

Copy link

@home-assistant home-assistant bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @BlackHoleFox

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@home-assistant
Copy link

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants