I also tried using different allowed_networks “192.168.0.0/24”…
By using the actual local ip address of my hass 192.168.178.26:8123 instead of hassio.local:8123 and deleting the cache, I was able to access the Configurator.
Try adding 172.30.0.0/16 to the list of allowed networks. The configurator runs as a docker container and receives an IP in that range. I’ve heard before, that allowing the Docker-network solved similar problems.
I was just pointing out that if you use a sesame, you can’t use trusted networks unless I’m reading the docs incorrectly. If I want to connect externally, my network will change all the time so the sesame is the best option. Configurator works perfectly using chrome on my iPad it’s just the iOS app that is borked.
Correct. Without the sesame you would need to either need an empty allowed_networks (which disables the filter), or add 0.0.0.0, which also means that connections from anywhere are allowed. The sesame enables you to set the allowed_networks like in my post above, so access from the local network is no problem. And if you connect from outside you network, the sesame kind of tells the configurator “I’m not within a trusted network, but I know the secret token, so please let me in anyway”.
So are you saying I can set allowed networks to 172.30.0.0/16 AND use a sesame? I thought from the docs you could not use a sesame if the allowed networks was used?
Huh, I think you might have directed me to a potential bug. But first to your question: yes, you can use both. In fact the sesame simply adds the IP off the connecting client to the list off allowed networks on the fly. So if you were to start the configurator without any allowed networks, but connect to it with the sesame, then over time you’ll add all those IPs you have connected from to the list of the allowed networks. That why I also have added the network-menu where you can manually remove old addresses. Those also get purged as soon as the configurator is restarted.
About that bug:
As I said above, leaving the allowed networks option empty (you can’t to that with the hassio addon though I believe) disables the IP filter. In that case you wouldn’t even need the sesame. But if you were to use the sesame anyway, then you would whitlist access from that IP, but clients that don’t use the sesame would never be able to connect. The addition via sesame enables the IP filter, which in turn leads to local clients not having an entry in the allowed networks option.
This case should never really happen because it doesn’t make sense to enable the sesame while not specifying networks which are allowed (and thereby enabeling the filter).
yeah it’s only refusing to connect in the iOS app iFrame. So the app isn’t using the sesame then? I am sure it used to work and I once just cancelled rather than entering a username and password and ever since I’m locked out (in the app)
If you get the Policy not fulfilled error, then access if blocked by the IP filter (which you would bypass with the sesame). If you don’t get that error, it would be something else.
By the way, the addon for hassio just has been merged.
No auth header is directly related to some failure while authenticating. At the point where the authentication is checked you already have passed the IP-check. The only SSL errors you can get would be the usual warning that the certificate is somehow invalid, or you get a response / content that doesn’t match the protocol. Often times the browser then says something like “Empty response” or similar.
Do you get any error messages? And maybe wait a few minutes. My PR just has been merged a few minutes ago. Maybe there are still some images that have to created. I’m unsure about the prerequisites and how long it takes for an update to be successful. Sorry for the inconvenience.
