Allow WLED access behind reverse proxy #2788

Dr-Bix · 2022-09-18T23:06:28Z

These changes should allow for devices to be referenced from URL mappings to different devices as well as via HTTPS from a HTTPS Reverse Proxy.

So the WLED Controller can still be accessed by the internal IP. In addition, a web server can be setup to reverse proxy to the internal device allowing outside access. This can also include Basic Auth over the connection for added security. While not perfect, Basic Auto over HTTPS is very good, not perfect, but is a simple solution to protecting your WLED Devices.

I am using a Raspberry Pi 3 with NGINX running in a docker container on the Pi.

My NGINX Configuration File looks like this (some of it is commented out from debugging but I left it around). I've also removed some info from the config for my own privacy.

server {
  listen 443 http2 ssl;
  listen [::]:443 http2 ssl;

  server_name localhost [removed for PR].com www.[removed for PR].com;

  access_log  /var/log/nginx/host.access.log  main;

  ssl_certificate     /usr/share/nginx/ssl/[removed for PR].crt;
  ssl_certificate_key /usr/share/nginx/ssl/[removed for PR].key;


  location / {
    try_files $uri $uri/ =404;

    root /usr/share/nginx/html;
    index index.html index.htm index.nginx-debian.html;
  }

  location /wled-bar/ {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;

    proxy_pass http://192.168.1.210/;
    proxy_buffering off;
    proxy_read_timeout 90;

    auth_basic              "Username and Password Required";
    auth_basic_user_file    /etc/nginx/conf.d/.htpasswd;

    # WebSocket Support
    proxy_http_version          1.1;
    proxy_set_header Upgrade      $http_upgrade;
    proxy_set_header Connection   "upgrade";
  }

  location /wled-bar/ws {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;

    proxy_pass http://192.168.1.210/ws;
#    include         proxy_params;
    proxy_buffering off;
    proxy_read_timeout 90;

    # WebSocket Support
    proxy_http_version            1.1;
    proxy_set_header Upgrade      $http_upgrade;
    proxy_set_header Connection   "upgrade";
  }
}

These changes should allow for devices to be referenced from URL mappings to different devices as well as via HTTPS from a HTTPS Reverse Proxy.

Aircoookie · 2022-10-20T09:17:20Z

I would like to merge this as I believe such a proxy setup is a viable way to securely expose your WLED devices to public networks.

Since I don't have personal experience with proxies, for links to be added in the future, is this correct?

Root-relative URLs (/settings) do not work
URLs relative to the current page (settings) work (and ./settings is the same thing?)
Relative go up 1/2 levels (./..) works
Absolute URLs (http(s)://<IP>/settings) work

One more point: In principle I like the sessionStorage['baseurl'] approach, but in the case the user directly navigates to a settings page without loading the UI first (which I often do), it could lead to an invalid URL (undefined/settings). Would need something like sessionStorage['baseurl'] ? sessionStorage['baseurl'] : '' but that is janky. Do you have another idea?

blazoncek · 2022-11-25T11:55:08Z

Since I don't have personal experience with proxies, for links to be added in the future, is this correct?
* Root-relative URLs (`/settings`) do **not** work
* URLs relative to the current page (`settings`) work (and `./settings` is the same thing?)
* Relative go up 1/2 levels (`.`/`..`) works
* Absolute URLs (`http(s)://<IP>/settings`) work

Anything behind reverse proxy may have intermediate path inserted.
So a http://wled.local/settings/leds may become http://www.public.com/device/settings/leds as seen in browser but ESP will still see /settings/leds request (from proxy).
As AsyncWebServer has no concept of folders within URL and UI does not know if it is dealing with reverse proxy some mechanism has to be employed in UI to deal with possible /settings/leds vs. /somepath/settings/leds and more important, calling JS and loading JSON files with intermediate path included or not.

Dr-Bix · 2022-11-25T14:26:22Z

Cool. I'll take a look at this in the next few days, the holidays have been very busy. I'll also make sure every use case for complex URLs works properly and will try to document it accordingly. 1. I do like the baseurl approach. It just needs to be initialized if it doesn't exist. I thought I did that, but will double check. 2. Root relative is another thing I'll have to check. I'm surprised they don't work. I posted the HTTPS Nginx configuration. The HTTPS Reverse Proxy just forwards requests from a particular URL to a HTTP Server. What ever paths are specified are forwarded verbatim. The added benefit is having multiple WLED "Servers" running on different URL Paths. So if I have two, the external endpoints could be: https://www.drbix.com/barled -> http://192.168.1.69 https://www.drbix.com/barled/settings/../settings -> http://192.168.1.69/settings/../settings https://www.drbix.com/kitchen -> http://192.168.1.72 I tested this using Basic Auth over HTTPS which is much better than just regular basic auth over http <https://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https>. It's not SCI type secure, but for this type of application, it's definitely a lot more secure. Also, I'll check absolute URLs through the proxy; they should work but I'll double check to be 100% sure. I would think that all of your bullet points below should work fine. The proxy just takes everything after the base URL and puts in the base URL of the WLED that was mapped in the Nginx Configuration.

On Fri, Nov 25, 2022 at 6:55 AM Blaž Kristan ***@***.***> wrote: Since I don't have personal experience with proxies, for links to be added

in the future, is this correct? * Root-relative URLs (`/settings`) do **not** work *This should work fine* * URLs relative to the current page (`settings`) work (and `./settings` is the same thing?) * Relative go up 1/2 levels (`.`/`..`) works * Absolute URLs (`http(s)://<IP>/settings`) work *This should also work fine* Anything behind reverse proxy may have intermediate path inserted. So a http://wled.local/settings/leds may become http://www.public.com/device/settings/leds as seen in browser but ESP will still see /settings/leds request (from proxy). *correct* As AsyncWebServer has no concept of folders within URL and UI does not know if it is dealing with reverse proxy some mechanism has to be employed in UI to deal with possible /settings/leds vs. /somepath/settings/leds and more important, calling JS and loading JSON files with intermediate path included or not. *I updated it so the AsyncWebServer works as expected. It had been a bit since I played with the WebSockets stuff, but it came back pretty quickly. I'll dig through the changes to document it better.* — Reply to this email directly, view it on GitHub <#2788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDEFVW5HXJ4BCF6CUFYL3WKCSKNANCNFSM6AAAAAAQPUOYVE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

…

On Fri, Nov 25, 2022 at 6:55 AM Blaž Kristan ***@***.***> wrote: Since I don't have personal experience with proxies, for links to be added in the future, is this correct? * Root-relative URLs (`/settings`) do **not** work * URLs relative to the current page (`settings`) work (and `./settings` is the same thing?) * Relative go up 1/2 levels (`.`/`..`) works * Absolute URLs (`http(s)://<IP>/settings`) work Anything behind reverse proxy may have intermediate path inserted. So a http://wled.local/settings/leds may become http://www.public.com/device/settings/leds as seen in browser but ESP will still see /settings/leds request (from proxy). As AsyncWebServer has no concept of folders within URL and UI does not know if it is dealing with reverse proxy some mechanism has to be employed in UI to deal with possible /settings/leds vs. /somepath/settings/leds and more important, calling JS and loading JSON files with intermediate path included or not. — Reply to this email directly, view it on GitHub <#2788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDEFVW5HXJ4BCF6CUFYL3WKCSKNANCNFSM6AAAAAAQPUOYVE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Dr-Bix · 2022-11-25T14:30:15Z

My bad, I misread your question in bullet point 1. Root relative URLs *MIGHT *be an issue. There may also be methods to fix this such as what is pointed out in this article <https://serverfault.com/questions/932628/how-to-handle-relative-urls-correctly-with-a-nginx-reverse-proxy> .

…

On Fri, Nov 25, 2022 at 9:26 AM Dave Bixler ***@***.***> wrote: Cool. I'll take a look at this in the next few days, the holidays have been very busy. I'll also make sure every use case for complex URLs works properly and will try to document it accordingly. 1. I do like the baseurl approach. It just needs to be initialized if it doesn't exist. I thought I did that, but will double check. 2. Root relative is another thing I'll have to check. I'm surprised they don't work. I posted the HTTPS Nginx configuration. The HTTPS Reverse Proxy just forwards requests from a particular URL to a HTTP Server. What ever paths are specified are forwarded verbatim. The added benefit is having multiple WLED "Servers" running on different URL Paths. So if I have two, the external endpoints could be: https://www.drbix.com/barled -> http://192.168.1.69 https://www.drbix.com/barled/settings/../settings -> http://192.168.1.69/settings/../settings https://www.drbix.com/kitchen -> http://192.168.1.72 I tested this using Basic Auth over HTTPS which is much better than just regular basic auth over http <https://security.stackexchange.com/questions/988/is-basic-auth-secure-if-done-over-https>. It's not SCI type secure, but for this type of application, it's definitely a lot more secure. Also, I'll check absolute URLs through the proxy; they should work but I'll double check to be 100% sure. I would think that all of your bullet points below should work fine. The proxy just takes everything after the base URL and puts in the base URL of the WLED that was mapped in the Nginx Configuration. On Fri, Nov 25, 2022 at 6:55 AM Blaž Kristan ***@***.***> wrote: > Since I don't have personal experience with proxies, for links to be added in the future, is this correct? * Root-relative URLs (`/settings`) do **not** work *This should work fine* * URLs relative to the current page (`settings`) work (and `./settings` is the same thing?) * Relative go up 1/2 levels (`.`/`..`) works * Absolute URLs (`http(s)://<IP>/settings`) work *This should also work fine* Anything behind reverse proxy may have intermediate path inserted. So a http://wled.local/settings/leds may become http://www.public.com/device/settings/leds as seen in browser but ESP will still see /settings/leds request (from proxy). *correct* As AsyncWebServer has no concept of folders within URL and UI does not know if it is dealing with reverse proxy some mechanism has to be employed in UI to deal with possible /settings/leds vs. /somepath/settings/leds and more important, calling JS and loading JSON files with intermediate path included or not. *I updated it so the AsyncWebServer works as expected. It had been a bit since I played with the WebSockets stuff, but it came back pretty quickly. I'll dig through the changes to document it better.* — Reply to this email directly, view it on GitHub <#2788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDEFVW5HXJ4BCF6CUFYL3WKCSKNANCNFSM6AAAAAAQPUOYVE> . You are receiving this because you authored the thread.Message ID: ***@***.***> On Fri, Nov 25, 2022 at 6:55 AM Blaž Kristan ***@***.***> wrote: > Since I don't have personal experience with proxies, for links to be > added in the future, is this correct? > > * Root-relative URLs (`/settings`) do **not** work > * URLs relative to the current page (`settings`) work (and `./settings` is the same thing?) > * Relative go up 1/2 levels (`.`/`..`) works > * Absolute URLs (`http(s)://<IP>/settings`) work > > Anything behind reverse proxy may have intermediate path inserted. > So a http://wled.local/settings/leds may become > http://www.public.com/device/settings/leds as seen in browser but ESP > will still see /settings/leds request (from proxy). > As AsyncWebServer has no concept of folders within URL and UI does not > know if it is dealing with reverse proxy some mechanism has to be employed > in UI to deal with possible /settings/leds vs. /somepath/settings/leds > and more important, calling JS and loading JSON files with intermediate > path included or not. > > — > Reply to this email directly, view it on GitHub > <#2788 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACDEFVW5HXJ4BCF6CUFYL3WKCSKNANCNFSM6AAAAAAQPUOYVE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

netmindz · 2023-06-02T10:29:53Z

Why are you trying to map different WLED devices by path? Would make much more sense to do based on hostname, that is normally how to access different hosts

blazoncek · 2023-06-02T13:42:27Z

@netmindz I can see the appeal of https://wled.myhome.com/kitchen/ and https://wled.myhome.com/porch/ as opposed to multiple hosts.

netmindz · 2023-06-03T14:30:10Z

which is ...?

Dr-Bix · 2023-06-03T16:41:49Z

It's been a long time and I've been absent for the most part (real-life issues), but getting back into the groove of things. I'm hoping, if this feature is still desired, to go back in and either rewrite it in the latest version or fix this branch. I'm open to suggestions.

blazoncek · 2023-06-03T17:48:38Z

which is ...?

http://kitchen.wled.myhome.com
Or
http://porch.myhome.com

As you suggested. And which works as is BTW.

netmindz · 2023-06-05T18:23:03Z

When proxying any web application, it is much more common to proxy pass the entire host rather than a single path. While some web apps can handle being mapped to a different path, you often hit other issues like the use of cookies, session storage etc as the hostname is used as the key for these. These might not be an issue for WLED right now, but I would bet that developers of future functionally would not consider the impact of multiple copies of the app differentiated by only path.

While this PR might end up containing all the right changes, as this is an a-typical use with non-trivial deployment and testing requirements it is likely to break in the future.

Given that for either host based or path based you are going to have a fair amount of manual setup for each node unless you use some funky regex or similar, it's not like you really save a lot on path-based approach, beyond adding an extra cname DNS record per node, unless wildcard is used.

blazoncek · 2023-06-05T19:17:42Z

BTW beta-3 branch has reverse proxy functionality implemented and it seems it is working correctly on my set-up.
I took a slightly different approach to allow independent workings of each and every page regardless of any previous visit.

It allows both ways - host based or path based reverse proxy.

Dr-Bix · 2023-06-05T19:56:16Z

That's great man, sorry this fell off my plate. I'll definitely test stuff.

…

On Mon, Jun 5, 2023 at 3:17 PM Blaž Kristan ***@***.***> wrote: BTW beta-3 branch has reverse proxy functionality implemented and it seems it is working correctly on my set-up. I took a slightly different approach to allow independent workings of each and every page regardless of any previous visit. It allows both ways - host based or path based reverse proxy. — Reply to this email directly, view it on GitHub <#2788 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACDEFWY2KZISJQS3NVVKRTXJYWGDANCNFSM6AAAAAAQPUOYVE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

blazoncek · 2023-07-31T19:43:20Z

Superseded by #3238

Working on changes to HTML and JS files for paths

be1e151

These changes should allow for devices to be referenced from URL mappings to different devices as well as via HTTPS from a HTTPS Reverse Proxy.

Aircoookie deleted the branch wled:main October 19, 2022 22:52

Aircoookie closed this Oct 19, 2022

Aircoookie reopened this Oct 20, 2022

Aircoookie changed the base branch from 0_14 to main October 20, 2022 07:58

Merge branch 'main' into path_changes_to_support_subpaths_and_https_TEMP

feb03de

Aircoookie mentioned this pull request Oct 21, 2022

Use relative paths for all links. #1970

Closed

blazoncek changed the title ~~Working on changes to HTML and JS files for paths~~ Allow WLED access behind reverse proxy Nov 25, 2022

blazoncek mentioned this pull request Jan 31, 2023

Settings page not working on reverse proxy #3069

Closed

1 task

softhack007 mentioned this pull request May 13, 2023

Allow WLED to be used through a Proxy #3201

Closed

blazoncek mentioned this pull request Jun 13, 2023

Beta 3 #3238

Merged

blazoncek closed this Jul 31, 2023

Uh oh!

Allow WLED access behind reverse proxy #2788

Allow WLED access behind reverse proxy #2788

Uh oh!

Conversation

Dr-Bix commented Sep 18, 2022

Uh oh!

Aircoookie commented Oct 20, 2022

Uh oh!

blazoncek commented Nov 25, 2022

Uh oh!

Dr-Bix commented Nov 25, 2022 via email

Uh oh!

Dr-Bix commented Nov 25, 2022 via email

Uh oh!

netmindz commented Jun 2, 2023

Uh oh!

blazoncek commented Jun 2, 2023

Uh oh!

netmindz commented Jun 3, 2023

Uh oh!

Dr-Bix commented Jun 3, 2023

Uh oh!

blazoncek commented Jun 3, 2023

Uh oh!

netmindz commented Jun 5, 2023

Uh oh!

blazoncek commented Jun 5, 2023

Uh oh!

Dr-Bix commented Jun 5, 2023 via email

Uh oh!

blazoncek commented Jul 31, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants