Hardcoded scheme and port in firmware update url

[kvolden]

The file management.js, lines 593 and 597, sets the firmware update url as 'http://' + $scope.hostName + ':8084/cgi-bin/main.cgi'. This causes two problems:

1. It forces the scheme to http, even if you are accessing through SSL, as you are when using find.z-wave.me or any other SSL proxy. This causes an unsafe scripts/mixed content error. Even if you accept loading unsafe scripts, it would make an unencrypted request for the firmware update page (which is bad in itself, but especially bad given issue Security issue: Passwords stored in cookie #198).

2. It forces the port to 8084, which tends to be incorrect when using find.z-wave.me or any other SSL proxy, resulting in a refused connection.

Suggested fix:

Currently, $scope.hostName is set in base.js to location.host, which does not contain the scheme or port number. While location.origin contains both, it is not supported on IE <11 and Opera <15.0. However, location.protocol will return the scheme in all browsers, and location.hostname will return the hostname and the port in all browsers. So the best fix is probably to add $scope.origin (or replace $scope.hostName, as it doesn't seem to be used elsewhere), and set it to location.protocol + '//' + location.hostname, and build the firmware update url with $scope.origin + '/cgi-bin/main.cgi'.

[PoltoS]

All this is pretty useless, since the 8084 service is not accessible via find.z-wave.me anyway (you are not in the network, while proxifying is not done for it).

It is in theory possible to proxify it too, but I would not suggest to update your box via remote access, as remote access will be stopped in the middle and you will get a brick ;)

[kvolden]

I'm not sure I understand. I know the 8084 port isn't accessible via find.z-wave.me, which is why hardcoding the port 8084 into the url results in a refused connection. The same could likely be true when using a local nginx proxy for SSL support as well.

Regarding bricking when updating via remote access, how is this the case? When I update the z-way firmware on my rpi through its web interface from my laptop, z-way starts downloading the new firmware, and then installs and restarts itself when the download is finished. Nothing has been bricked. Why would doing this by proxy cause it to brick?

EDIT: If what you're saying is that cgi-bin/main.cgi isn't accessible through find.z-wave.me, because updating through find.z-wave.me would cause it to brick, then I suppose that's a separate issue. But still, if you derive the scheme and port from location in the firmwareUpdate url like I suggested, instead of hardcoding to http and 8084, it would allow for it to behave correctly when accessing through a local SSL proxy. For those of us preferring this solution over a non-SSL local connection and the find.z-wave.me service, it would at least maintain SSL integrity. :)

[PoltoS]

upgrade is done srep by step. first 8084, then Z-Way. Then you do it remotelly, 8084 shuts down too early and second phase might not even start. So you will result in old Z-Way + stopped 8084

[kvolden]

I see, but then you're talking about find.z-wave.me specifically, right? Because I've always updated Z-Way through the web interface on port 8084 remotely from a different computer and never experienced any bricking. With my own SSL proxy, that should still technically work, right? Except it will in that case at best break SSL integrity.

I don't really see any downsides of also getting scheme and port, and not only host, though location instead of hardcoding it, and I don't see any benefits in keeping it the way it is. If it's a time and/or resource issue for you, I can make the change myself when I get the time and create a pull request. :)

[PoltoS]

Indeed, we have not considered tricks like nginx for local SSL. For that case it makes sence.

Sure you can make a pull request - we are out of time to do that and would appreciate your contribution!