evcc in iFrame - cannot access restricted / protected area

[michiproep]

Describe the bug

When I show evcc within an iFrame - in my case within an iobroker vis - it is not possible to enter a password protected / restircted area.
After entering the password nothing happens. When you show evcc normal in the browser, everything works as expected.

Steps to reproduce

...

Configuration details

---

Log details

---

What type of operating system are you running?

Linux

Version

0.126.2

[andig]

I would simply say that we‘re not supporting iframes. They are a thing from the past imho.

/cc @naltatis

[michiproep]

@andig : generally, I agree. But within home automation tools which usually run in Kiosk mode where you plug a bunch of different things within a common start page, this is the only way and still very common.

But when I think about it, it might not be a evcc bug... May-be, it's due to "browser vendors restricting cookies in iFrames". Not sure what evcc does with the password? Does it issue a session cookie?

[StefanSchoof]

Are both (iobroker and evcc) via http or is one or both https?

[naltatis]

@michiproep magst du mal nen Screenshot der Konsole in den Browser-Devtools posten? Mir ist bisher nicht ganz klar, was da schiefgeht. Ein erfolgreicher Login setzt ein http-only Cookie. Das sollte auch im iframe funktionieren. Gibt da aber in der Tat einiges an Security Settings, die sowohl die Host- und Inkludierte-Seite setzen kann.

[mdkeil]

Keine Ahnung, ob ich Äpfel mir Birnen vergleiche-- bei mir läuft evcc in HA in einer Website-Kachel (aber via https), da funktioniert die Auth ohne Probleme.. ich glaube, dass dort aber kein iframe genutzt wird.

[michiproep]

Neue Info: Scheint nur im Edge zu aufzutreten.
Und ja, bei mir läuft intern alles nur unter http.
Konsole zeigt das hier:

[naltatis]

@michiproep Ok danke. Ich versuch das mal nachzustellen.

[michiproep]

Ich glaub, ich habs gefunden. Der Cookie Header hat kein SameSite Attribut.
Browser scheinen einen unterschiedlichen Default Wert zu verwenden.
In meinem Fall bräuchte ich "None", aber aus Security-Sicht sollte das wohl konfigurierbar sein...

Vielleicht im yaml ein "allowIFrame"?

[naltatis]

Ich kann deinen Fall leider immer noch nicht reproduzieren. evcc in iFrame eingebettet im Edge funktioniert bei mir ohne Fehler. Für das Auth-Cookie ist aber Same-Site: strict eigentlich die saubere/sichere Lösung. Ich nehm das mal in den Master. Bitte teste mal morgen mit dem Nightly ob es dein Problem löst.

[michiproep]

ok. danke. Ich muss mir mal ein Testsystem für den nightly aufsetzen...
Aber mit "strict" erwarte ich eigentlich, dass es nirgends mehr funktioniert. Mal schauen...

[michiproep]

Hi @naltatis , wie erwartet funktioniert das mit "strict" jetzt nirgends (kein Browser) mehr...
Können wir nicht "strict" als default machen, aber im yaml überschreibbar machen?

[naltatis]

Ok, hab mich jetzt mal ausführlicher mit dem "Iframe" Anwendungsfall beschäftigt. Generell verhalten sich die Browser da sehr unterschiedlich. Gerade was Cookies ohne SSL angeht. Ich habe jetzt mal die Same Site Policy gelockert und Unterstützung für CHIPS hinzugefügt (siehe PR), um nicht von Anti-Tracking-Maßnahmen getroffen zu werden. Für ein stabiles Setup, das in allen Browsern und auch zukünftig funktioniert, sollte der iframe Inhalt auf jeden Fall per HTTP ausgeliefert werden.

[naltatis]

Ok, ist leider doch komplizierter. Siehe Kommentar im PR. @michiproep bindest du den iframe via https ein?

[michiproep]

Ok, ist leider doch komplizierter. Siehe Kommentar im PR. @michiproep bindest du den iframe via https ein?

Nein, alles http

[StefanSchoof]

@naltatis Wäre es eine Idee zu erkennen, ob evcc in Iframe läuft und wenn ja, an den Stellen wo das Passwort erforderlich ist, ein Link zum öffnen von evcc in einem neuen Tab anzubieten.

Das wäre für Nutzer bei denen es aktuell nicht klappt nicht optimal, aber ich Glaube wenn man als weniger technikaffine in das Problem läuft man Recht auf geschmissen ist.

[naltatis]

@StefanSchoof bin mir noch nicht ganz sicher, wie man das gut erkennen kann. Aber das wäre in der Tat erstmal eine einfache Lösung. Wenn wir iframe + auth + http zuverlässig unterstützten wollen werden wir vmtl. weg vom Cookie auf JWT in LocalStorage gehen müssen :/

[michiproep]

Hi @naltatis,
bei läuft ja alles nur lokal (bzw via VPN). Ich bräuchte eigentlich gar keinen Schutz...
Ich wäre eigentlich dafür, dass man Auth komplett abschalten können sollte.
Aber fall es aktiv ist, dann solltest du schon auf ein httpOnly/strict Cookie bestehen (und eigentlich auch auf secure, was aber https bedingt)

[StefanSchoof]

Laut Stack Overflow soll das mit

function inIframe () {
    try {
        return window.self !== window.top;
    } catch (e) {
        return true;
    }
}

gehen. https://stackoverflow.com/a/326076/4319676

[naltatis]

Hier jetzt erstmal der vorgeschlagene Hinweis wenn Login erfolgreich war (richtiges Passwort) aber der Zustand nicht gehalten werden kann (Passwort). \cc @StefanSchoof