Even though it’s very unlikely that someone else gets your IP and tries to hack you, you should always manually remove the IP from the list of allowed ones as soon as your done with your work. Removing work and instantly blocks you. Which you at first won’t notice because the page doesn’t reload. But doing anything that makes requests to the configurator fails from that point on. So consider removing the IP as logging out.
And of course: glad it works and you don’t have to expose the configurator to the whole web.
You get there by clicking the dots the arrow points to. In the list that in my case has two hosts and one network allowed you should see your public IP.
Hi Daniel.
Great job with Configurator!
I was wondering… When I try to access it through panel_iframe on the home assistant iPhone app, I get “no auth header received”. I tried using the new “sesame” function, but that also doesn’t seem to work.
If i try to do the same via chrome or safari on iPhone, it asks for a username and password.
I don’t have an iPhone, so I can’t test that. But I would suspect that that is a limitation of the App. If it doesn’t prompt you for credentials, then it’s not following common web standards.
The sesame function is not related to this. It is intended to whitelist IP addresses. That could be a workaround for not being able to enter valid credentials. But it would be a really really (really really!) bad idea to not require credentials if the configurator is exposed to the web. On top of that the App may not provide all the required HTML-capabilities to properly run the configurator.
My suggestion would be, that you access the configurator directly via a bookmark (optionally with the sesame to dynamically whitelist your IP) within the Safari browser. That shoud give you the best experience. The other option would be to notify the iOs-App developer of this issue so it can be fixed.
Setting SO_REUSEADDR on socket for proper restarts
Using Threading to handle multiple connections
New VERIFY_HOSTNAME option to block requests without correct host header
Fixed filebrowser hiding
The first two points probably are irrelevant to most users.
Fixing the filebrowser hiding hopefully makes a few of you happy. It was quite annoying hiding the filebrowser if you didn’t know what the problem was. This has been fixed. The downside is, that it’s possible that a few devices with a low resolution don’t show enough to still drag the filebrowser out of sight. The workaround for these devices would be to temporarily switch into landscape mode, which should reveal enough of the editor-area the tap away the filebrowser.
The VERIFY_HOSTNAME is intended for people who expose the configurator to the web directly without a reverse proxy. It requires the correct host header to be present in the request, or else it will return a 403 Forbidden error. This means that if yourdomain.example.com points to 1.2.3.4 and you previously could access the configurator by either the hostname or IP, this setting only allows access if the (correct) hostname was used. So if an attacker only knows your IP and you have a wildcard-certificate, he wouldn’t know the correct hostname and wouldn’t even get to the point where valid credentials could be entered.
I love the UI and am very impressed with the work that has gone into this. Nothing makes me happier than seeing a YAML editor built into HASS; trying to find a decent Android one has been a pain.
I’m running a very stock HASSBIAN install. I’ve installed the configurator.py script to /home/homeassistant/.homeassistant. It works great with sudo ./configurator.py. I’ve modified the BASEPATH to /home/homeassistant/.homeassistant. I’m trying to get Systemd to work and can’t.
The error that I receive on sudo systemctl status [email protected] (the file that I created) is code=exited, status=210/CHROOT; Failed with result ‘exit code’, Service hold-off time over, scheduling restart, Start request repeated too quickly, Unit entered failed state.
I’ve copied the systemd template directly and installed it as described in the HASS documents. I’ve tried both the stock template as well as modifying both of the addresses to include the “/.homeassistant” portion at the end. Both seem to generate the same errors as above.
Does all this point to something unbelievably stupid that I’ve done? What else can I report for troubleshooting?
With that in place I used systemctl enable hass-configurator.service to enable the service, and to control it I use systemctl status hass-configurator.service.
This is running on a hassbian system with no special customization. So for you this should work as well.
Hey - thanks for sending that. It made me notice what I didn’t change out of the template: the “/etc/homeassistant” portion (I had it pointing to “/etc/homeassistant/.homeassistant” which was clearly the issue). I also wasn’t running it as root.
As suspected, it was a dumb mistake. I wonder, though, if a couple of different templates for systemd files could pop into the GIT to prevent these sorts of dumb errors.
Yeah, the path of course depends on where people put the file. I have it in the homeassistant folder, but the guy who made the template obviously does not. Having multiple templates in the repository doesn’t appeal to me though. And since this is the first time this issue came up I believe it won’t be a problem most of the time.
And yes, I do run as root since I also use the configurator to edit other files on the system. That’s not best practice though. I have my setup pretty secure since I’m rather paranoid. So for me it’s not a problem. Usually though it would be better to run as the homeassistant user.
I’ve tried to do the proxy redirect on nginx for that but it fails due to /api/whatever calls from the UI.
Basically UI loads, but when i tries to call it’s backend it ignores the URL path where it runs. Seems it expects that it is always accessed from the server root.
Is there a way to set the baseURL for the hass-configurator itself, so it calls its APIs on a correct URL? Or isn’t it enough to just call “api/whatever” instead of “/api/whatever” (relative path, not absolute to server root).
just as a note, it’s quite a fresh install so everything should be at it’s latest versions.
This should be working. First thing that hits my eye: append a / to the path you have configured. When using a reverse proxy (which is what you want to do), a path always ends with a /. Leaving away the / would reference a single resource like a single html-file or image or whatever.
So edit your nginx config to include the trailing slash and access the configurator with that updated path.
A brief description of the event observer:
Inspired by this thread I implemented a simple WebSocket client that subscribes to the event-stream via the HASS API. If it connects successfully, all events that happen on HASS’ event-bus are printed in their raw format for you to analyze. If for example you have a new button-device and want to figure out what kind of event it emits, just follow the output of the event observer.
This is basically the same as running HASS in the debug log-level and following the log, minus everything that’s being logged that’s not event-related.
The configurator tries it’s best to guess how the API can be reached on its own (basically at the same location where it accesses the HASS API itself). This should work pretty well if you have the HASS_API option set to your external host (like when you expose to the internet). If it’s set to localhost because it’s running on the HASS host, then of course this can’t work because you usually don’t have HASS running the client-machine. In this case you have to manually enter the correct URI.
) so much easier.