Hi.
I use a ssh tunnel to port forward and connect to my hubitat. When using the following URL to access a dashboard of switches and trying to toggle a switch I just get an hourglass. Action actually succeeds but the dashboard never refreshes. On enabling developer console on chrome, I saw the following error logs. Seems like a straightforward issue of mal-constructed URI which assumes that the base is just an IP or host and doesn't account for the generic authority form.
This problem showed up after upgrading to dashboard 2.0.
More details:
Broken if I use the following URI
http://localhost:7800/apps/api/115/dashboard/146?access_token=[redacted]&local=true
Works when I use the other form
http://192.168.1.248/apps/api/115/dashboard/146?access_token=[redacted]&local=true
error log from JS console
Thanks.
I also noticed dash board items not updating
1 Like
I got the same issues now as well.
1 Like
Are both of you also port forwarding via an ssh tunnel?
Afraid I can't really help here. Dashboard isn't intended to work via port forwading and via an ssh tunnel. That's why we have the cloud dashboards.
Because you are forcing it to a different port, the websocket isn't going to be able to connect.
It should however fail over to polling even while on local connections, so that might be a bug, it takes about 5 retries on the failed websocket connection before it should switch over to polling.
Thanks for your response Patrick! Shouldn't it be possible to check and modify the URI from "ws://localhost:7800:80/eventsocket" to "ws://localhost:7800/eventsocket" where ever in the code the URI is being constructed? Seems like a simple bug in construction of URI more than anything else. I was reading more about websockets and nothing in the RFC prohibits ports other than 80. Of course, there might be other implications from your perspective of using a non-standard port which I am not aware of. But in this specific case, ISTM, it should be an easy fix. What do you think?
The main reason for me to switch to hubitat was that I could ensure that absolutely nothing is happening on a remote server which is not in my control. Using a cloud based dashboard goes against that basic value proposition of hubitat. I hope you can understand and appreciate why this is a cause of concern for me
And you can't use a VPN? You'd rather port forward an ssh tunnel?
I've submitted a feature request but it isn't as easy of a fix as you think it might be.
We already have to switch ports for ssl enabled connections, adding a means to detect someone redirecting port 80 or 443 to a non standard port might sound simple but in reality, it's impossible to detect an attack vector vs a reasonable request or to easily determine if that redirect is secure or not.
I get that you want this to work the way you set it up, but it is way out of scope for how we intend Hubitat to work. Never the less it's on the list of things to look at as we evaluate feature requests and bug fixes.
I looked extensively into using VPN before zeroing in on ssh tunnels. Couple of big reasons to drop that idea
- It's a big hit on throughput and the only use case to have it would be access to my hub
- Once again, I have to depend on outside paid services over which I have little control or trust
- It's very hard to only have some of the traffic go thru VPN; I have to set up routing table and such which is hard to do on a (or many) mobile device.
I understand the security concerns from your POV and appreciate those. I am hoping you'll be able to fix it or find a workaround
I think you may be confusing what VPN service is needed. You don't need one of the paid VPN service that anonymize you browsing. You need to setup VPN access into you home network. A lot of modern routers have this capability baked in. You can also set up a Rpi to be your VPN server.
I looked into that as well. Having all my mobile/laptop traffic go thru a VPN server set at my home means that all the traffic (when I am not home) gets sent to my home router over the measly 10mbps uplink that my very expensive comcast connection provides (there are no other providers in my area. Yayyy for capitalism).
I do not port forward. To access my hub from WAN I use teamviewer. If I access a dashboard I have WAN ticked and use a pin.
I have your exact limitation and I simply do not leave my VPN connected when I don't need it. I connect when I need access to my home network...ie to administer HE, look at dashboards or look at my ip cams. I use Tasker (android app) to make this as simple as possible. I have an icon that when tapped will connect to my home VPN and open the HE home page. Another icon that connects and opens tinycam with my camera dashboard....etc. I also have a disconnect icon. It all really seamless for me.
1 Like
I do it a similar way... Connect to my OpenVPN when I need to do home stuff, turn it off when done... Took about 5 minutes to setup since my router already supported OpenVPN.
1 Like
stephack, JasonJoel: I think your approaches are quite reasonable (and maybe even slightly safer) as well. But, I had to device something which works seamlessly for my wife as well as other guests visiting the home. I use SPT (android app) to keep a persistent tunnel open which meant the dashboard always worked before
I am not using ssh. I am just grabbing the web link from the dashboard and using it.
You can always enable use legacy dashboards and go back or roll back firmware
I think you do not have to route all traffic through an openVPN.. just the subnet or ip you want. See "route-nopull" for the client which overrides forwarding all traffic.
Something like this:
route-nopull
route [Local HE Hub IP Address] 255.255.255.255
Which would set up a route just to the HE. I have not done this so cannot verify it works but you might want to look into it..
So here you can see I am connected directly to the hub website, looking at the dashboard and clocking in certain lights will result in the hourglass icon.
You are pulling that link from the dashboard section not the dashboard app config.. My url looks something like this:
http://10.10.3.93/apps/api/13/dashboard/404?access_token=xxxxxxxxxxxxxxx&local=true
Don't know if that makes a difference or not.
If it stays on an hourglass after clicking that means the device did not return a changed state. Confirm by doing the same command in the hub UI device details.
Otherwise the connection to the hub websocket was disconnected and didn't reconnect. There will be some improvement to this failover to polling in the next release.
1 Like
