Grafana Dashboard as Lovelace iframe results in ingress issue

[vistalba]

The problem

Use of Grafana Dashboards in Lovelace iframe isn't possible if Grafana is access is using ingress as sometimes there is no valid session on the ingress controller.

Environment

• Home Assistant Core release with the issue: Home Assistant 0.111.4
• Last working Home Assistant Core release (if known): -
• Operating environment (OS/Container/Supervised/Core): HassOS 4.10 / Supervisor 227
• Integration causing this issue: lovelace, grafana, ingress
• Link to integration documentation on our website:
  https://www.home-assistant.io/lovelace/iframe/
  https://github.com/hassio-addons/addon-grafana

Problem-relevant from lovelace card

aspect_ratio: 100%
type: iframe
url: >-
  https://myserver.dyndns.org:8123/api/hassio_ingress/3jHEB2kTvq7akBXc0Ggoy9SPbWfvkBlR9t1Z9vM3iLs/d/4QCBjC9Wz/stromverbrauch?orgId=1&refresh=5m&theme=light&kiosk=tv

Traceback/Error logs

[hassio.api.ingress] No valid ingress session None

Additional information

There were multiple people wishing a real solution for this issue. I think it is complex and needs to be discussed generally how to solve this issue.

As already stated here (https://community.home-assistant.io/t/401-unauthorized-iframe-card-of-grafana-not-working-on-the-www-local-network-ok/148017/21), the issue can't be resolved by grafana addon, as if the error occours there is no traffic that reaches the grafana docker container.

So the problem has to be resolved before (ingress/lovelace webpage card?)

There are a workaround out there but with real downsides.

The workaround is to enable a port for ingress in the grafana addon and allow anonymous login.
The downside in this solution is:

a) remote access to grafana dashboard needs additional port (e.g. additional port-forwarding on router)
b) anonymous login needs a role in grafana. If role is viewer I'm also just a viewer if I access the grafana over the link in the left. So I can't edit anything. If role is editor or admin everyone with access to configured port can edit everything.

So for my usecase this is really not desired. I want to shared just some dashboards but no one exept the HA admin should edit any of the dashboards. For this case there is no solution.

May be possible solutions:

• Add possiblity to create new "ingress session" from a lovelace webpage card? ( https://myserver.dyndns.org:8123/api/hassio/ingress/session )
• Add possibility in grafana for anonymous=viewer but if logged in by ingress session (click grafana in left pannel) be admin.
• Add possibility to use bearer token based auth in lovelace webpage card?

May there will be other possibilities I don't know at the moment.

[frenck]

The issue is that de frontend doesn't have a valid authenticated session via ingress for the add-on, until the normal ingress route has been visited.

After that, the iframes work. This is not just a Grafana add-on issue. It applies to any add-on providing ingress.

[vistalba]

@frenck Exactly that is the issue. But it would be useful to have a solution for this usecases.
May it would be a solution to add a possibility to lovelace (as an option) first open a ingress route?

[frenck]

Maybe 🤷
I'm not a frontend guy. I'm just familiar with the issue, hence my additional comment (and I moved this issue to the frontend project).

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[mkarnebeek]

This is still relevant. Tested on 0.115.

[ludeeus]

This is not a bug, this is how iframes work.
Marked as a feature request.

[shaxxx]

Are there any known workarounds (beside opening Grafana WebUI to create ingress session)?
Some of things I wanted to try were

• rewrite all requests for specific Grafana url to Grafana port 3000. Unfortunatelly, customizing nginx addon configuration seems impossible to me.
• include API key in the url. Not sure how to do this yet, maybe custom html file with jquery request including bearer token.

Any other ideas?

[mkarnebeek]

I've worked around it by having nginx in front of it redirect requests from /api/hassio_ingress/KyY4m.... to the port i've opened up for grafana. This is normally insecure as it bypasses ingress authentication (allthrough grafana has it's own login), but i'm handling authentication in nginx.

[shaxxx]

@mkarnebeek This is something I'm trying to accomplish.
Did you use standalone separate nginx installation or hass nginx addon?
I'm banging my head trying to configure simple

location /some/path/ {
    proxy_pass http://www.example.com/link/;
}

[shaxxx]

@ludeeus I will just quote a part of hass documentation
Ingress allows Hass.io add-ons to seamlessly integrate their user interface with Home Assistant. Home Assistant will take care of the authentication and the secure connection, so users can start using the add-on directly, without any configuration necessary by the users. It just works.

It doesn't work. It's not a feature request.

[ludeeus]

It does work, from the sidebar where that feature is intended to be used.
This thread is about embedding it as an iframe in a Lovelace dashboard.

[jwhite]

@ludeeus Why would anyone want to generate dashboard elements that you can't use and share? That is the reason graphana exists.

[spali]

For OPs first possible solution:
Wouldn't it be possible to have a flag in the iframe card settings to set, which does a js call to create an ingress session before loading the iframe url? This would be backward compatible in all cases.
A more user friendly approach would be to detect ingress urls and do it automatically. But don't know the internals, if the card has access to differentiate if the url is an ingress path.

Other possibility (but I think a feature of core) would be to support relative redirect for ingress calls.
For grafana addon the page is available at http://10.1.0.8/a0d7b954_grafana but I can't append relative urls after this to be directly redirected to the requested subpath like a specific dashboard. If this would work, I assume we could just use: http://10.1.0.8/a0d7b954_grafana/my_requested_relative_path and ingress auth is handled the same as going to the addon ingress via the sidemenu.
This would also allow the addon developers to also have a configurable "external url" which should work from anywhere in a predictable way.

[sim-san]

I am also interested in a solution

[CraigHoffmann]

As an interim bandaid solution I have done the following:

I made a new “web card” on my main home assistant landing page with the link copied from the grafana link in the side panel... "https://xxxxxxxx.duckdns.org:8123/a0d7b954_grafana". Set the Aspect Ratio to 0% and leave the title blank and the card will effectively be hidden (may be better ways to do this?)

It's not perfect but now when I open home assistant in a new browser or on a new device the hidden web card authorises to grafana and then my grafana cards display fine. (So I don't have to first click on the grafana link in the side panel)

Note all my grafana chart cards are on a different view/tab in home assistant to my main landing page so the hidden authorisation webcard connects before I change to the views with grafana charts. Haven't tried if it works when they are on the same view/tab in home assistant.

[vistalba]

For me this workaround is not working on iOS :( Anyone else tested the suggested workaround?

[ninamarie8253]

Im having this very problem. I just updated Grafana and I think that made it worse, not sure what to do here. Tried adding the configuration bits that others have suggested on other forumns, tried resetting the cache, tried port 300 and port 8123, nothing works. How do we solve this? I just want to view my graphs inside Home Assistant on my phone.

[felipecrs]

@dermotduffy once suggested me that it should be proxied by a Home Assistant integration before the Lovelace card can access it.

dermotduffy/advanced-camera-card#331 (comment)

This is how Frigate card ends up communicating with the Frigate addon (through the Integration which proxies the necessary endpoints).

[vgdh]

I get 401: Unauthorized on grafana in iFrame card.
After I update the page it works fine.
It looks like its don't get some authentication token for api/hassio_ingress and therefore it wouldn't load shared graph in Iframe.
I use VM.
Home Assistant Core 2022.6.4
Home Assistant Supervisor 2022.05.3
Home Assistant OS 8.1

[fthiery]

For the record i encountered the same problem by trying to use an hassio Zigbee2Mqtt ingress URL (like homeassistant://api/hassio_ingress/XXXXXXXXXX/#/device/0x70ac08fffe87636c/info) as "Visit" device link.

(See home-assistant/core#96100 ad home-assistant/core#96107)

NB: in the above, the homeassistant:// prefix is being replaced by the current page domain automatically

Possible solutions to cover the two usecases (being iframes and "Visit" button):
A) the frontend needs to be modified to detect the usage (anywhere in the page) of URLs with /api/hassio_ingress and call createHassioSession if necessary
B) when a user accesses Lovelace UI for the first time, the frontend could preventively create the Hassio Session

I think B is simpler

Is there a more general discussion for this ingress session problem ?

Any other ideas ?

[slavendam]

I think B is simpler

Is there a more general discussion for this ingress session problem ?

Any other ideas ?

Here is solution which does that - generates hassion session automatically:
lovelylain/ha-addon-iframe-card#6

[dankarization]

Still relevant in 2026 and affecting real users.

I just hit this again in a live Home Assistant deployment while embedding the Music Assistant add-on UI inside a Lovelace dashboard for non-admin users. The symptoms are the same as described earlier in this thread:

• the normal add-on panel route works;
• a plain Lovelace iframe/webpage card pointed at the ingress URL does not reliably work unless an ingress session already exists;
• for end users this turns into a broken or infinitely loading dashboard experience.

In our case we confirmed that the add-on itself was fine and accessible, but the dashboard embed path failed until ingress session handling was worked around on the frontend side.

The workaround that solved it for us was a custom Lovelace card that explicitly creates/validates the ingress session before loading the iframe (ha-addon-iframe-card). That is useful as a workaround, but it also confirms the missing piece appears to be in frontend/core behavior, not in the add-on.

So from a user perspective this is not just an old Grafana quirk. It still affects modern add-ons like Music Assistant and it still pushes people toward custom cards, hidden pre-auth pages, or bypassing ingress entirely.

A native fix still seems worthwhile. The most obvious options still look like:

1. Teach the built-in webpage/iframe card to detect ingress URLs or add-on slugs and create/refresh ingress sessions automatically.
2. Provide a first-class ingress-aware Lovelace card in frontend/core instead of forcing custom cards.
3. Make frontend routing/session handling robust enough that homeassistant://... / ingress-based navigation and embedding do not depend on a previously visited sidebar panel.

If a new proposal/issue is the preferred place now, please point to it and I can add a more exact reproduction from this Music Assistant case.

[dankarization]

Proposal: First-class ingress-aware embedding for Lovelace iframe/webpage cards

Problem statement

Home Assistant add-ons that rely on Supervisor ingress do not embed reliably inside Lovelace when rendered through the built-in iframe / webpage card.

In practice, the add-on itself is healthy and reachable, but the embedded UI may fail to load, show 401 / No valid ingress session, or get stuck in an infinite loading state until the user first visits the add-on through its normal sidebar/panel route.

This is still affecting real users in current versions of Home Assistant and is not limited to Grafana:

• Grafana dashboards embedded in Lovelace
• Zigbee2MQTT links using ingress-based frontend URLs
• Music Assistant embedded for non-admin / kiosk / dashboard-only users

The current situation forces users into workarounds:

• visit the add-on panel first to "warm up" ingress
• bypass ingress and expose a direct port
• add hidden pre-auth cards/views
• install custom cards such as ha-addon-iframe-card

That is a bad UX and pushes users away from the built-in dashboard primitives.

Current behavior

Today, the standard Lovelace iframe / webpage card behaves like a generic iframe wrapper:

• it accepts a URL
• it renders the iframe
• it does not manage ingress session lifecycle

For ingress-backed add-ons, this creates a mismatch:

1. the add-on expects a valid Supervisor ingress session
2. the Lovelace card loads the URL without ensuring such a session exists
3. the iframe fails unless the session was already created elsewhere

Related navigation behavior also remains awkward:

• direct panel routes may work, but they are not always suitable for kiosk/dashboard-only users
• ingress-based URLs with fragments or router-sensitive paths have historically hit frontend routing edge cases
• users embedding add-on UIs in dashboard flows often need a clean "open inside dashboard and go back" experience, not a sidebar detour

Desired behavior

Home Assistant frontend should provide a first-class way to embed ingress-backed add-on UIs inside Lovelace without custom cards.

Expected behavior:

1. If a Lovelace card points to an ingress-backed add-on, the frontend should transparently ensure a valid ingress session exists before the iframe is loaded.
2. While the card remains mounted, the frontend should keep that session valid as needed.
3. The behavior should work equally for admin and non-admin users, subject to the add-on's own access rules.
4. Users should not need to visit the sidebar panel first.
5. Users should not need to expose direct ports or weaken security to make embedding work.

Minimal frontend/core design

Option A: Upgrade the existing webpage/iframe card

Teach the built-in card to recognize ingress-backed targets, for example:

• /api/hassio_ingress/...
• add-on slugs / ingress routes
• homeassistant://... ingress-style URLs where applicable

When such a target is detected:

1. call Supervisor ingress session creation before initial load
2. store/reuse that session in the frontend
3. validate/refresh the session while the card is active
4. then load the iframe

This is the smallest UX change because it preserves the existing Lovelace card concept.

Option B: Introduce a dedicated ingress-aware Lovelace card

Add a new first-party card, for example:

• type: addon-webpage
• type: ingress-webpage

This avoids overloading the generic iframe card and makes the special behavior explicit.

Possible config:

type: ingress-webpage
addon: d5369777_music_assistant
path: /
aspect_ratio: 150%

Advantages:

• clearer mental model
• easier docs
• lower risk of surprising behavior for generic external URLs

Shared implementation note

The backend building blocks already exist conceptually: the missing piece is mainly frontend orchestration of ingress session lifecycle around embedded usage.

Compatibility / risk notes

Security

This proposal should not bypass ingress or weaken auth.

It should only automate the same authenticated ingress session flow that already works when users open the add-on through the intended panel route.

Scope boundaries

This proposal is about ingress-backed add-ons embedded in Lovelace.
It is not about arbitrary third-party iframes on the open web.

Backward compatibility

If implemented as detection inside the existing webpage card, care is needed to avoid changing behavior for normal external URLs.

That is why a dedicated first-party ingress-aware card may actually be safer.

UX edge cases

Even with ingress session handling fixed, dashboard-only flows still need good navigation patterns.
That is separate from session creation itself, but worth acknowledging in docs/examples:

• kiosk users may need a built-in back action
• mobile users may not see the sidebar
• full-panel add-on experiences inside dashboards are valid use cases

Why this matters

This is no longer just an old Grafana issue.
It affects current real-world dashboard use cases with modern add-ons like Music Assistant.

The existence of successful community workarounds such as ha-addon-iframe-card is strong evidence that users need this behavior and that the missing functionality is small but important.

The question is not whether ingress-backed embedding is useful.
Users are already doing it.

The question is whether Home Assistant wants this solved natively in frontend/core, or to keep pushing users toward custom cards and brittle workarounds.

Suggested ask to maintainers

Would the frontend team accept either:

1. a proposal to make the built-in webpage card ingress-aware for add-on URLs, or
2. a small first-party ingress-aware Lovelace card with explicit Supervisor session handling?

If yes, I can turn this into a narrower implementation proposal with:

• exact detection rules
• session lifecycle expectations
• suggested YAML/API shape
• risk boundaries
• test scenarios based on Grafana, Zigbee2MQTT, and Music Assistant

[dankarization]

I opened a new broader discussion for this as a general Lovelace/add-on ingress embedding problem, not just a Grafana-specific one:

#52204

That new thread is framed around current use cases including Music Assistant and Zigbee2MQTT, plus a concrete proposal for first-class ingress-aware embedding in frontend/core.