POST-Redirect: Übermittelte Attribute wie lesen?

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • POST-Redirect: Übermittelte Attribute wie lesen?

    Hallo zusammen,

    ich kämpfe momentan mit einem Problem, dass mich langsam verzweifeln lässt. Folgendes Szenario:

    Ein Anwender wird von mir zum Login auf einen anderen Server umgeleitet. Dort läuft ein Authentifizierungsverfahren eines Drittanbieters ab, welches bei erfolgreicher Durchführung die von mir benötigten Daten via HTTPS POST-Redirect mit Code 301 zurücksendet.

    Soweit alles gut. Umleitung, Login und Redirect laufen. Auch zeigt mir ein Mitschnitt von Firebug, dass die Rückgabe funktioniert und alle Parameter vorhanden sind.

    Versuche ich aber, eben diese Daten auszugeben, erhalte ich nur leere Arrays.
    PHP-Code:
    //.......................
    var_dump($_GET); 
    var_dump($_POST); 
    var_dump($_REQUEST); 
    var_dump($_FILES);
    var_dump($_ENV);
    var_dump($_COOKIE);
    print_r($_SESSION);
    var_dump($_SERVER);
    var_dump($GLOBALS);
    //....................... 
    Alles gezeigte liefert nur leere Arrays. Meine Frage ist nun, ob ich vollkommen falsch an die Sache herangehe. Bisher war ich es gewohnt, übergebene Parameter via $_GET bzw. $_POST oder halt auch mal in einer Session zu verwalten.

    Den Betreiber des Loginverfahrens hatte ich dazu auch bereits kontaktiert, erhielt von dort aber nur folgende Antwort:
    wie in der Schnittstellendefinition beschrieben, werden im Erfolgsfall die ausgelesenen Daten als verschlüsselter String per HTTPS POST Weiterleitung an das aufrufende Fachverfahren zurückgegeben. Es sind also an der URL keine sichtbaren Parameter vorhanden.
    Ebenso Google wollte mir nicht so recht weiterhelfen.
    Sollte ich in den letzten zwei Tagen einfach nur zu dumm gewesen sein, um den Fehler zu finden, würde ich mich sehr über den einen oder anderen hilfreichen Tipp freuen.

  • #2
    Ein Redirect mit Statuscode 301 sorgt dafür, dass der Browser einen GET-Request macht – in so einem Fall ist also nichts mit POST.

    307/308 würden zwar erlauben, dass der Redirect ebenfalls einen neuen POST-Request auslöst – aber selbst das würde nur bedeuten, dass die ursprünglich von deinem Browser geposteten Daten noch mal woanders hingeschickt würden – um eine „Antwort“ von deinem Remote-Authentifizierungs-Dienst zu erhalten, taugt auch diese Methode nicht wirklich.

    Kannst du mal zeigen, wie dein Firebug-Mitschnitt aussieht?
    I don't believe in rebirth. Actually, I never did in my whole lives.

    Kommentar


    • #3
      Ja, sowas hatte ich auch schon gelesen, aber wie gesagt, auch im GET findet sich leider nichts.

      Was genau von Firebug möchtest du denn sehen? Ich habe mal zwei Screenshots mit dem Header der Antwort sowie den Parametern umd die es geht angehangen.

      Für mein Verständnis. Wenn es vom Browser als GET-Request behandelt wird, muss ich mich im Quellcode auf $_GET stützen. Ist das so richtig?

      Sorry für die vielleicht dumme Frage.
      Angehängte Dateien

      Kommentar


      • #4
        Zitat von Peter_Schaper Beitrag anzeigen
        Für mein Verständnis. Wenn es vom Browser als GET-Request behandelt wird, muss ich mich im Quellcode auf $_GET stützen. Ist das so richtig?
        Theoretisch ja.

        Aber der zweite Request in deinem ersten Screenshot hat als Request-URI nur /tbktest/, da scheinen keinerlei GET-Parameter enthalten zu sein.

        Der erste Request im zweiten Screenshot, was ist das für einer? Kopfzeile ist im Screenshot abgeschnitten, ist das ein GET oder POST, und mit welchen Parametern, und an welche Domain?

        Gibts von dem Authentifizierungs-Anbieter eine öffentlich verfügbare Doku, wie der Prozess abzulaufen hat?
        I don't believe in rebirth. Actually, I never did in my whole lives.

        Kommentar


        • #5
          Also der erste Screenshot zeigt den Redirect nach Login zur Anwendung zurück. Und eben ja. Es gibt dabei keinerlei GET-Parameter. Beim zweiten Screenshot handelt es sich um denselben Fall, nur dass ich dort auf die POST-Parameter gescrollt habe.

          Ich habe nochmal zwei Screenshots angehangen. Jeweils der Post- bzw. der Get-Anteil des Redirect vom Loginserver zur Anwendung.

          Es gibt vom Anbieter eine Schnittstellendefinition. Leider ist diese nicht öffentlich verfügbar. In dieser ist auch nur enthalten, wie die Parameter aufgebaut sind und wie sie gesendet werden:
          Die Rückgabewerte werden per HTTPS POST-Redirect (Code 301 [Moved Permanently]) an
          das Fachverfahren zurückgesendet. Die URL ist beim Aufruf im Parameter SPRedirect
          anzugeben.
          Nach deinem Hinweis auf den GET-Request versuche ich aktuell, den Body der Antwort auszuwerten. Leider bisher ohne Erfolg.
          Angehängte Dateien
          Zuletzt geändert von Peter_Schaper; 18.02.2016, 11:33. Grund: Anhänge hinzugefügt

          Kommentar

          Lädt...
          X