Ergebnis 1 bis 18 von 18

Thema: Contao Login in iFrame

  1. #1
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard 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.
    Geändert von mikefmmedia (03.05.2022 um 17:22 Uhr)

  2. #2
    Contao-Fan Avatar von BennyBorn
    Registriert seit
    10.06.2011.
    Ort
    Edenkoben
    Beiträge
    268
    Partner-ID
    6916

    Standard

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

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

  3. #3
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    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?

  4. #4
    Contao-Fan Avatar von BennyBorn
    Registriert seit
    10.06.2011.
    Ort
    Edenkoben
    Beiträge
    268
    Partner-ID
    6916

    Standard

    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...

  5. #5
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    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.

  6. #6
    Contao-Fan Avatar von BennyBorn
    Registriert seit
    10.06.2011.
    Ort
    Edenkoben
    Beiträge
    268
    Partner-ID
    6916

    Standard

    Zitat Zitat von mikefmmedia Beitrag anzeigen
    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.

  7. #7
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    \Input:ost('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

  8. #8
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Gesicht zeigt die Zunge

    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.

  9. #9
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    35.517
    Partner-ID
    10107

    Standard

    Poste einen Link zur Seite, wo sich der iframe befindet.
    » sponsor me via GitHub or PayPal or Revolut

  10. #10
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    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.

  11. #11
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    35.517
    Partner-ID
    10107

    Standard

    Ja, könnte eine CSP der Host Seite sein.
    » sponsor me via GitHub or PayPal or Revolut

  12. #12
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    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');
    Geändert von mikefmmedia (05.05.2022 um 13:25 Uhr)

  13. #13
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    35.517
    Partner-ID
    10107

    Standard

    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.
    » sponsor me via GitHub or PayPal or Revolut

  14. #14
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

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

  15. #15
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Standard

    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.

  16. #16
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    35.517
    Partner-ID
    10107

    Standard

    Zitat Zitat von mikefmmedia Beitrag anzeigen
    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).
    » sponsor me via GitHub or PayPal or Revolut

  17. #17
    Community-Moderator
    Wandelndes Contao-Lexikon
    Avatar von Spooky
    Registriert seit
    12.04.2012.
    Ort
    Scotland
    Beiträge
    35.517
    Partner-ID
    10107

    Standard

    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.
    » sponsor me via GitHub or PayPal or Revolut

  18. #18
    Contao-Nutzer
    Registriert seit
    02.04.2021.
    Beiträge
    84

    Daumen hoch Gelöst

    Zitat Zitat von Spooky Beitrag anzeigen
    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>

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •