Proper reverse tunnel support?

📢 Feedback Feature Requests
1

I run a reverse proxy using Apache to give myself external access to a bunch of different things running inside my network. I have a hack that mostly works for Hubitat to allow that access: Hubitat over HTTPS/SSL using Apache

Would it be possible to have the hub WebUI be aware of it's currently served protocol + domain so we don't need to do content substitution? I noticed that the local dashboard links stopped working because the UI started always putting "http://" as the protocol instead of using the current protocol from the browser.

2

Unfortunately, no. The local links use the websocket to connect and many browsers now block https / wss connections to unsigned certs.

We continue to explore additional options but this is why we provide the cloud relay.

3

I'm using a signed cert (yay letsencrypt) and the websockets work just fine:

    # Enable request rewriting for proxy (mod_rewrite)
    RewriteEngine On
    # Rewrite requests with a Upgrade=websocket header to the ws port (mod_proxy_wstunnel)
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /(.*)           ws://hubitat:80/$1 [P,L]
    # Rewrite requests without a Upgrade=websocket header to the http port (mod_proxy)
    RewriteCond %{HTTP:Upgrade} !=websocket [NC]
    RewriteRule /(.*)           http://hubitat:80/$1 [P,L]

All I really want is localIp to be set from window.location.host and to use window.location.protocol when generating URLs

   # Rewrite the localIp variable to use the page host and force https for localIp URLs
    AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE text/html text/plain text/xml application/javascript
    Substitute "s|var localIp = \"[^\"]+\"|var localIp = window.location.host|i"
    Substitute "s|http://\"\+localIp\+\"/|\"+window.location.protocol+\"//\"+localIp+\"/|"

The instructions I linked work and are generally reliable enough for me that I can monitor logs and do driver/app development remotely. Just these two minor tweaks to the JS code would remove the need for doing regex rewriting of the responses to fix host/protocol hardcoding.

4

Afraid this breaks normal https local dashboards then due to the above issue I outlined.

Until a solution exists that doesn't break it for everyone not using a reverse tunnel on https and their own signed cert, this isn't going to change.

5

Huh, I guess I don't follow. Are you saying people are using local https dashboards right now? Why does just using the current browser protocol & host instead of hard-coding http and IP break other local usage? For anyone that currently uses http for access using the .protocol field would be a noop change.

Making those same changes that the regex is making via browser tools when accessing the hub directly still works as the generated URLs don't change from what the hub would otherwise be generating.

1 Like
6

I want to bring this back from the dead because it's still very relevant and with the move to paid cloud subscription since is more important than ever. In a post I just made, the salient if salty point i think should be stressed (Hubitat over HTTPS/SSL using Apache - #52 by simple):

So again to renew this request, it would be as simple as just not hardcoding the http://<LOCAL HOST> in static ref/links and setting the hubURL: window.location.host since it appears the HE is internally aware of whether the request is coming from within the LAN (subnet) or externally in order to decide how to treat it - though i'm assuming the https://cloud.hubitat.com/api/... cloud link is itself a proxy/wrapper and rewrites the static links to a respective CDN store.

The point here is KISS and occam's razor in assessing this feature request. It's not changing anything but removing a (now poor security practice) uri component and letting the browser fill in the blanks.