Contao Login in iFrame

Hallo Zusammen,
ich binde Contao auf einer externen Seite mit einem iFrame ein. Contao ist hier nur dazu da einen Login anzuzeigen und wer sich (im iFrame im Contao) einloggt, wird dann einfach auf eine externe Seite weitergeleitet (auch im iFrame). Ich habe dafür das Logintemplate überschrieben, darin checke ich ob der User korrekt eingeloogt ist und wenn ja dann weiterleiten.

Das ganze hat bis heute noch funktioniert, aber seit heute funktioniert es nicht mehr im iFrame, wenn ich die Contao-Loginseite jedoch direkt im Browser öffne aber schon.
Ob der Benutzer eingeloggt ist checke ich mit $this->logout, das ist aber im iframe immer leer.


Mein Logintemplate

PHP-Code:

---

<?php
if ($this->logout) {

    // Redirectlogik, das wird normalerweise ausgeführt, aber der iframe geht hier nicht rein weil $this->login leer ist.
}
?>

...Standard Loginhtml ....

---

Der Systemlog im Contaobackend schreibt, User "xy@domain.at" has logged in. Also funktioniert hat es anscheinend irgendwie schon, aber das $this->logout ist trotzdem bei Login im iframe leer und bei Login direkt auf der URL = 1.

Hab anstatt $this->logout auch mal System::getContainer()->get('contao.security.token_checker')->hasFrontendUser(); versucht, das gibt im iframe false und auf der direkten Seite true zurück.

Liegt am Nelmio Security Bundle. Folgendes in die config/config.yml packen (ungetestet)

Code:

---

nelmio_security:
    clickjacking:
        paths:
            '^/.*': ALLOW

---

Danke, habs probiert und auch Symphonycache geleert, aber leider kein Erfolg.

Auch mit folgendem gings nicht.

Code:

---

nelmio_security:
    clickjacking:
        paths:
            '^/.*': 'ALLOW-FROM https://domain-wo-der-iframe-eingebunden-ist.de'

---

---
Hab jetzt auch noch in die htaccess was geschrieben, aber das hilft glaub ich nur wenn die Seite gar nicht im iFrame geladen wird.

Code:

---

    <IfModule mod_headers.c>
        Header always append Content-Security-Policy "frame-ancestors 'self' *.die-domain-auf-der-der-iframe-ist.de"
    </IfModule>

---

Hat das nicht irgendwie damit zu tun, dass vlt das Cookie vom iFrame nicht gelesen werden kann, oder der Requesttoken nicht mitgeschickt wird oder so?

Habe jetzt keine 4.13 mit Mitglieder-Login, daher habe ich es einfach mal mit dem Backend-Login versucht.
Das Verhalten ist bei mir das gleiche. Laut System-Log eingeloggt aber ich bleibe eben auf der Login-Maske. Sehr strange...

Kann man die POST-Daten irgendwie selber abfragen im mod_login.php, damit ich dann selber Username und Passwort mit der Datenbank abgleichen kann?

Habe folgendes im Template versucht abzufragen {{post::username}}, $this->Input->post('username'), $_POST['username'] , aber die sind immer alle leer.

Zitat:

---

Zitat von mikefmmedia

Kann man die POST-Daten irgendwie selber abfragen im mod_login.php, damit ich dann selber Username und Passwort mit der Datenbank abgleichen kann?

Habe folgendes im Template versucht abzufragen {{post::username}}, $this->Input->post('username'), $_POST['username'] , aber die sind immer alle leer.

---

$_POST['username'] sollte eigentlich gehen, mit der Input-Klasse müsste es

PHP-Code:

---

\Input::post('username'); 


---

lauten. Kann aber sein das, weil die Authentifizierung komplett in Symfony überführt wurde, die POST-Variablen aus Sicherheitsgründen gelöscht werden und somit nicht am Template ankommen.

\Input::post('username'); ist leider auch leer.

Ich hab es jetzt soweit, dass ich mit unserialize($_SESSION['_sf2_attributes']['_security_contao_frontend']); sowas raus bekomme (mit dump):

Code:

---

^ Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken {#869 ?
  -credentials: null
  -firewallName: "contao_frontend"
  -user: Contao\FrontendUser {#870 ?
    #strTable: "tl_member"
    #strCookie: "FE_USER_AUTH"
    #strLoginPage: null
    #arrGroups: null
    #roles: array:1 [?]
    #intId: null
    #strIp: null
    #strHash: null
    #arrData: array:6 [?
      "id" => "68"
      "username" => "email@example.at"
      "password" => "$2y$13$...."
      "disable" => ""
      "start" => ""
      "stop" => ""
    ]
    #salt: null
    #arrCache: []
    #arrObjects: []
  }
  -roleNames: array:1 [?]
  -authenticated: true
  -attributes: []
}

---

Nur schaffe ich es hier nicht auf die Userdaten zu zugreifen.

Code:

---

$postdata = unserialize($_SESSION['_sf2_attributes']['_security_contao_frontend']);
dump($postdata['user']); //geht gar nicht, bzw führt zu error
dump($postdata->{'user'}); //ist null

---

Hab das ganze jetzt auch nochmal mit Contao 4.9.29 getetstet, selbes Problem.

Das ist jetzt echt ein massives Problem, da das demnächst live gehen soll :(
Komischerweise hatte die Anmeldung mit Weiterleitung im iFrame schon funktioniert. Hab das ja schon mit dem Kunden durchgespielt, shit mir fällt grad nichts mehr ein was ich versuchen könnte.

Poste einen Link zur Seite, wo sich der iframe befindet.

Denn echten Link kann ich leider nicht schicken, aber danke für den Wink. Habe jetzt darum das ganze mal in einer eigenen Seite mit iFrame getestet und da geht es jetzt tatsächlich wieder.
Nur bei der externen Seite (Fremdserver) gehts nicht, dh ich muss wohl deren IT mal fragen ob die irgendwelche Servereinstellungen in letzter Zeit geändert haben die das vlt verursacht haben könnten.

Ja, könnte eine CSP der Host Seite sein.

Ok, der Test vorher wo es ging war auf dem selben Server. Habe es jetzt nochmal auf 2 verschiedenen Servern probiert, also Host ist auf anderem Server als die Seite im iFrame und jetzt konnte ich den Fehler (auf unseren Servern) wieder reproduzieren.

Testseite https://contaobasic.fm-media-staging.at/test.html

Zur Info, ich habe es so eingestellt, das die Emailadresse als Benutzer verwendet werden muss. Das war glaub ich das Schnippsel in contao/dca/tl_member.php

Code:

---

$GLOBALS['TL_DCA']['tl_member']['config']['onsubmit_callback'][] = array('tl_member_sendmail', 'sendMail');

---

Die URL https://mze360.mze-staging.at/?stand=1304 hat im Response Header

Code:

---

content-security-policy: frame-ancestors 'self' *.mze.de *.mze.at www.mze.de www.mze.at *.fm-media.at *.mike.fm-media-staging.at https://360.mze.de/stand/1231 https://contaobasic-4-13.mze-staging.at/ *.fm-media-staging.at
content-security-policy: frame-ancestors *

---

Also die frame-ancestors CSP wird zwei mal im Response Header gesetzt - und die zweite Variante ist möglicherweise ungültig.

Das war einmal die .htaccess und das zweite von Nginx. Habe das zweite mal entfernt, aber leider kein Erfolg.

Also ich vermute da jetzt ehrlich gesagt ein Problem in Contao (oder Symphony) bzw deren Sicherheitssysteme, den Contao schreibt ja sogar einen Logeintrag im Backend, dass ich mich eingeloggt habe, obwohl es aus Frontendsicht ja nicht funktioniert hat.
Dh. Logindaten müssen angekommen sein, die sehe ich ja auch im Logintemplate mit

Code:

---

unserialize($_SESSION['_sf2_attributes']['_security_contao_frontend']);

---

, aber irgendwas in der Pipeline sagt "ok du bist eingeloggt, aber eigentlich nicht" ...oder so.

Ich glaube ich muss mich jetzt mit Hooks durcharbeiten, vlt werde ich da schlauer oder kann das irgendwie umgehen.

Zitat:

---

Zitat von mikefmmedia

Das war einmal die .htaccess und das zweite von Nginx. Habe das zweite mal entfernt, aber leider kein Erfolg.

---

Folgendes steht immer noch im Response Header:

Code:

---

content-security-policy frame-ancestors 'self' *.mze.de *.mze.at www.mze.de www.mze.at *.fm-media.at *.mike.fm-media-staging.at https://360.mze.de/stand/1231 https://contaobasic-4-13.mze-staging.at/ *.fm-media-staging.at

---

Sollte aber passen, da damit ja der Parent (https://contaobasic.fm-media-staging.at/test.html) erlaubt sein sollte (durch *.fm-media-staging.at).

Der Grund ist SameSite=Lax bei den Cookies von Symfony/Contao. Damit Cookies, die von einem iframe gesetzt werden, vom Browser akzeptiert werden, muss SameSite auf None sein. Das kann glaube ich über die Config kontrolliert werden, weiß aber die entsprechende Config nicht auswendig.

Zitat:

---

Zitat von Spooky

Der Grund ist SameSite=Lax bei den Cookies von Symfony/Contao. Damit Cookies, die von einem iframe gesetzt werden, vom Browser akzeptiert werden, muss SameSite auf None sein. Das kann glaube ich über die Config kontrolliert werden, weiß aber die entsprechende Config nicht auswendig.

---

@Spooky, DANKE, das mit SameSite wars. Bin da zwar auch mal kurz im MDN-Blog vorbeigeschrammt, aber hat mich wohl nicht getriggert.

Setting habe ich in der .htaccess so eingepflegt, falls das noch wer braucht:

Code:

---

    <IfModule mod_headers.c>
        Header always edit Set-Cookie (.*) "$1; SameSite=None; Secure"
    </IfModule>

---