How to deal with non-SSL Panel iframe pages inside SSL Hass.io environment?

I use it as a haos add-on. You can type almost any URL in it and it should work as is, just it says ‘frigate’. So I Literally just

Config.yaml to change the panel label so it doesn’t say frigate and icon and default ports.
Everything under LABEL in the dockerfile.

And a couple of Nginx settings under rootfs/etc/Nginx/ proxy params or server params if I wanted something different for a specific service, like removing x-frame-options because cross site scripting preventing rendering website on another website.

I attempted to set up the Integration but it wouldn’t let me. Can you give me an example of the things changed? ENV Variables are easy enough to overwrite in a Docker-Compose, like if the default logo image is at /etc/www/images/frigate.png you can set a volume mapping in Docker-Compose to take your file /home/docker/frigate/happyface.png:/etc/www/images/frigate.png to replace that. & if it’s pulling the title for the label from the Variable $BUILD_NAME you can set an ENV in Docker BUILD_NAME=Smiley you just need to know what variable needs to be replaced.

Where are you typing the URL?

In the config.yaml? The URL variable there is to a GitHub so it’s set value is not the internal one.
In the Frigate Integration? That one if you put a URL without camera feeds gives a Failed to connect response if it doesn’t have a camera feed

I’m working on making a version that can be customized with ENV variables in Docker. Knowing where the URL you referenced is will be a big step to making it work. Aside from that I’m just still not sure how to add it to Home Assistant.

But I ran into a problem…
You said you customized the Dockerfile correct?
When trying to build from the Dockerfile, even unmodified, I have a problem, possibly because it is missing ENV variables that the Home Assistant Supervisor would have

failed to parse stage name "ghcr.io/hassio-addons/debian-base/:5.1.0": invalid reference format

that’s coming from this line at the begining of the Dockerfile

ghcr.io/hassio-addons/debian-base/${BUILD_ARCH}:5.1.0

I discovered that it needs, in my case amd64 & if I sub that in it works, but if you modified it how did you get around that?

When you install it as an add-on, the configuration page has input for ‘server’ where you can put an IP:port or fqdn:port (no http/s ://)

The things I changed are basically the name of the addon, and my private repo link and icons.

So for something like sonarr, or radarr, it’s changed to sonarr proxy, or radarr proxy. And it’s just loading whatever webpage you input into the ‘server’ option.

Thats all it’s doing, is making it so home assistant is loading the webpage, not you as the client. Its kinda like an iframe, but not. Iframe expect the client to connect to the end server and load the resources.

As far as the dockerfile, I’m using it as an add-on, so when home assistant builds it, it has those dependencies available?

1 Like

Thanks for that information. I’ve learned that the BUILD_ARCH & BUILD_FROM are internally getting arguments from a build.yaml file & a config.yaml or config.json file that, unlike traditional Docker, set arguments for the build not just runtime. I’ve still yet to learn how Supervisor gets which argument, but I assume it’s a default set by the version that Supervisor itself uses, so if Supervisor is AND64 it passes that to every $BUILD_ARCH call, & the BUILD_FROM is essentially the same thing, except it has a “if AND64 use this link, if ARMHF use this link, if ARM7 use this one, etc”

From another thread I learned that apparently you’re using a tool called Ingress from the Frigate Proxy add-on & the part that adds the integration. Hopefully I’ll be able to get this to work as a standalone Docker Container

It’s AMD64 not AND64.

I referred you to the docs earlier, but ingress is documented here, in case you missed it. Presenting your addon | Home Assistant Developer Docs

Ingress is intimately tied to supervisor, which is not to say that there are not other ways to do what you want.

Sorry, typo, AMD64 was intended. Since it happened multiple times it was probably Autocorrupt & I didn’t notice.

You did, but you referenced an entire manual in a statement saying “they do more” & “supervisor supervises” & gave a link that said

Add-ons for Home Assistant allow the user to extend the functionality around Home Assistant. This can be running an application that Home Assistant can integrate with (like an MQTT broker) or to share the configuration via Samba for easy editing from other computers. Add-ons can be configured via the Supervisor panel in Home Assistant.

Under the hood, add-ons are container images published to a container registry like GitHub container registry and Docker Hub. Developers can create GitHub repositories that contain multiple add-ons for easy sharing with the community

Then had a tutorial on making an add-on…
All that in response to “Why not have an add-on repo”… Which didn’t really answer the question.

In another forum I was pretty much told that Ingress (& config/build formatting) is almost solely what separates Supervisor from Docker. & specifically that that Frigate Proxy is utilizing Ingress & when I mentioned someone modifying it to use for a different URL was told essentially that they were just using Ingress from the container.
I’ll look more into it once my next billing cycle starts (as I’m already over my monthly cap this month). But how I do that, or if I will actually be able to with my modest skills, is still TBD. I may try to make an independent supervisor stack to run in regular docker & use a Portainer-like manager so it can run any add-on for a Docker HA, or it was suggested possibly making a Dockerized Ingress agent that could be slapped over a regular Docker Container & essentially give them the thing they lack from a HA side while retaining their superiority otherwise, then all other configuration will just have to be done manually &, so I’m told, it will make the Supervisor unnecessary.
I’m not sure which direction I’ll go, but most likely whichever seems easier or has the least steps requiring things I’m not skilled at. Either way I’ll share the results as either should be appropriate for this thread’s goals

1 Like

Not sure how I missed this, because I responded right below it. But this user has an ingress proxy written as well, @LostOnline

2 Likes

Thanks. That should be helpful if I take that path. But it’s, again, an add-on, so it will still have to be dockerized, but it’s definitely nice to have a cleaner source to reference

@LostOnline you may wish to read this thread Is it possible to convert an addon for HA OS to run in a standalone container for HA as a docker?

1 Like

This was sounding promising but I can’t get it working. I just end up with a blank screen after clicking ‘open wen ui’

addon log
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-banner.sh: executing... 
-----------------------------------------------------------
 Add-on: Frigate Proxy
 Proxy addon for Frigate
-----------------------------------------------------------
 Add-on version: 1.3
 You are running the latest version of this add-on.
 System: Home Assistant OS 9.4  (amd64 / generic-x86-64)
 Home Assistant Core: 2022.12.8
 Home Assistant Supervisor: 2022.12.1
-----------------------------------------------------------
 Please, share the above information when looking for help
 or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
[cont-init.d] 00-banner.sh: exited 0.
[cont-init.d] 01-log-level.sh: executing... 
[cont-init.d] 01-log-level.sh: exited 0.
[cont-init.d] nginx.sh: executing... 
[cont-init.d] nginx.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[14:38:37] INFO: Starting NGinx...

Also, it seems to not be using any resources…
image

I actually dug into this as well, ever since I migrated to a Docker installation and…actually have found the way to make it work using nginx proxy manager (either add on, or seperate docker). Here is how it works:

In NGINXProxy manager, you start with creating your proxy host as explained in the installation guide here:

After that, you need to create a rule for the location you want to access through https. So go to the “advanced” tab of your proxy host and enter a custom location with this code:

location /panelname/ {
    rewrite /panelname/(.*) /$1  break;
    proxy_pass  http://local-ip:port;
}

So this basically creates a rule, which forwards all requests to: https://yourdomain.duckdns.org/panelname to your network internal (non secure) http adress. But…since it goes through NGINX it is served as a secure site to the outside world.

Then, in your configuration.yaml you enter the panel_iframe like such.

panel_iframe:
  panelname:
    title: "Panel Name"
    url: "https://yourdomain.duckdns.org/panelname"
    icon: mdi:docker
    require_admin: true

I have got most things working flawlessly like this, just have a tiny issue left with the Duplicati container in my case, but most things like Zigbee2MQTT, Portainer, Configurator, Vaultwarden etc work flawlessly like this and I can access everything externally.

Hope this helps someone…

4 Likes

Hi, I also migrated my installation to docker standalone installation. Can you please share you config, ie. docker-compose file for nginx or give some additional info how you set this up.
Edit: Got it, it does work great. Maybe I latter wrote some my config just for people to find it.

This my docker-compose.yml file for nginx

  nginx:
    container_name: nginx_proxy
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - /opt/nginx/data:/data
      - /opt/letsencrypt:/etc/letsencrypt

I use dynu for my domain. Set up for ssl is really easy. Just grab ssl key from site and and replace token in a line

dns_dynu_auth_token = YOUR_DYNU_AUTH_TOKEN

I tried to open z2m over nabu casa using iframe and it does work. This is great, this is the thing I wanted to do for a few weeks. Some setups are more complex that others but this setup mention by @Remko is easy and this work great.
Thank you for sharing.

Hi. I applied your code and it is working with esphome and portainer but for frigate container it is not. Could you please help me to solve it? Thank you.

I used this code in Advanced tab

location /frigate/ {
    rewrite /frigate/(.*) /$1  break;
    proxy_pass  http://10.20.30.105:5000;
}

And this in HA configuration.yaml

  #frigate iframe
  frigate:
    title: frigate
    icon: mdi:webcam
    url: https://hass.local/frigate
    require_admin: true

Hi. I did managed to solve it using this help

This is working code in advanced tab for frigate container
!!!
USE IT ONLY ON YOUR LOCAL SERVER.
IT OPENS FRIGATE WITHOUT LOGIN TO HA
!!!

location /frigate/ {
    rewrite /frigate/(.*) /$1 break;
    proxy_set_header Host $host;
    proxy_set_header X-Ingress-Path "/frigate";
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_pass  http://10.20.30.105:5000;
}

HA configuration remains the same (see previous post)

This totally works- BUT anyone on the planet can go to

https://yourhomeassistantname.duckdns.org/panelname

and have full access because you’ve served it. Yes, it’s https: so nobody in the middle can interpret it, but whoever is attached can control whatever was served. Try it by opening a browser that isn’t logged into your instance of HA- put that in the browser. Which you may not care if it’s just your holiday lights or something.

Also, for anyone trying to do this with Logitech Media Server, it won’t work (something about local files).

They still need to login to Home Assistant

True, and I only serve some pages which require a separate login so could be fine.

@DavidFW1960 : no this is not true. The pages are served separate from Homeassistant and can be opened without even accessing homeassistant.

Yeah @fmon is damn correct. I found out it today also. I may browse my frigate instance even without login into HA. Thats really bad. USE IT ONLY ON YOUR LOCAL SERVER.

So @fmon and @Remko how to solve this?

Create authentication for the separate containers. For example Portainer or Z2MQTT are easy, they allow you to define a separate login. I don’t expose frigate to the outside, rarely need that webpage, the integration offers all I need.
Accessing that I do just in my internal network with a bookmark in my browser to the local ip:port

1 Like

And do you use for sth your proposed sollution?