PHP-Login mit serveruebergreifender Variablenuebergabe

[Galanos]

Hallo zusammen,

ich zerbreche mir gerade den Kopf ueber ein Problem(?) bzgl. Authentifizierung per PHP.

Folgende Situation:
Ich moechte fuer meine Kunden eine Art Portal anbieten, mit dem sie sich in ein CMS einloggen koennen, um die Inhalte auf ihrem Webspace (nennen wir ihn "kunde1.de") zu verwalten.
Das PHP-Script des Kundenlogins soll auf meinem Webspace liegen ("dienstleister.de") – was das eigentliche, grosse Problem ist.

Dafuer bin ich einige Moeglichkeiten durchgegangen:
1. Login-Script und CMS liegen auf "dienstleister.de", dabei ist die Schwierigkeit, dass ich keine Ahnung habe, wie ich meinem Script die Rechte gebe, Inhalte auf "kunde1.de" zu schreiben.

2. Login-Script liegt auf "dienstleister.de", CMS liegt auf "kunde1.de" und bekommt die zuvor geprueften Zugangsdaten vom Login-Script geschickt.

Ich habe mich fuer die zweite Moeglichkeit entschieden, habe auf "dienstleister.de" ein Formular fuer die Zugangsdaten gelegt, die Daten sollen geprueft werden und an das CMS auf "kunde1.de" geschickt werden.
Dort soll ein Cookie die Daten speichern und fuer die gesamte CMS-Session die Authentifizierung sicherstellen.

Ich hatte auch ueberlegt, auf "dienstleister.de" ein Cookie mit den Zugangsdaten zu erstellen, das mittels Domain-Attribut fuer "kunde1.de" gueltig ist, aber das funktioniert laut php.net nicht.

Also steh ich vor dem Problem, die Zugangsdaten aus dem Formular an das CMS, also zwischen zwei Servern, auszutauschen. Denn mit dem Abschicken des Formulars prueft das Login-Script erstmal, ob Benutzername und Passwort in Kombi gueltig sind, dann soll der User auf sein CMS auf dem jeweiligen Server (kunde1.de, kunde2.de etc., abhaengig vom Benutzernamen) weitergeleitet werden.
Bis hierhin kein Problem, ich lasse die Daten pruefen und den Benutzer per header()-Redirect auf sein CMS umleiten.
Aber wie uebergebe ich die Zugangsdaten? Per GET ist ja Unsinn, dann stuenden die Zugangsdaten offen lesbar in der Adresszeile. Und POST kann man meines Wissens nur ueber ein Formular nutzen.
Und dann muesste der Benutzer noch einmal den "Absenden"-Button bestaetigen, was ich auch nicht moechte. Kann man sowas per header() uebertragen?

Kann mir jemand 'nen Tipp geben, wie ich das anstelle? Oder mein Konzept vollstaendig umschmeissen, weil alles viel einfacher geht?

Waer euch echt dankbar.

 

[firewars]

So problematisch ist das gar nicht. Zunächst einmal: Du kannst POST-Daten auch ohne Formular und ohne Submit-Button übertragen. Geht ebenfalls mit header und ein paar anderen Funktionen (zum Beispiel fsockopen). Genaueres gibt's hier: Wie kann ich einen HTTP POST-Request absenden?.

Damit dürfte dein Problem eigentlich gelöst sein, oder? Du kannst die Daten ja einfach weiterleiten bzw. intern woanders hinposten. Wird fummelig, wenn es alle Daten betrifft. Wenn's nur der Login ist, ist das überhaupt kein Problem. Auch nicht sicherheitstechnisch, wenn du das Password als MD5-Hash versendest und mit dem MD5 des gespeicherten Passwortes (am besten liegt das auch nur als MD5 vor) abgleichst.

 

[moses_78]

Keine Ahnung, ob ich dein Problem richtig
erfasst habe....aber wenn es dir nur darum
geht, ein Formular an eine fremde Seite zu
schicken, sie dir mal dieses Script an (ist zwar
"nur" CLI-PHP, wird aber auf dem Webserver
mindestens ebenso gut laufen).

Das assoziative Array "$info" enthält dann
Informationen, u.a. wohin das Script umge-
leitet wurde.

PS. Damit das Script läuft, muss PHP mit
"--with-curl" kompiliert worden sein, KA,
wie das bei deinem Provider aussieht...

 

[Galanos]

Oh, vielen Dank fuer die Antworten Und willkommen im Forum, firewars.
Ich versuch's noch mal klarer darzustellen:
Wenn ich den Client per header()-Redirect zu "kunde1.de" schicke und ihm mittels GET die Login-Daten mitgebe, kann das CMS dort ihn uebernehmen und die Daten in einen Cookie packen, womit mein Problem geloest waer. Nur kann ich ja schlecht GET verwenden, es sollte schon POST sein, verschluesselt waer auch toll.

Ich schaue mir mal firewars' Vorschlag genauer an, klingt interessant. Nur besteht dort, glaube ich, das Problem, dass ich zwar POST-Daten an einen anderen Server schicke und sie dort verarbeitet werden koennen, der Client sich aber noch immer auf meinem befindet. Ich moechte ihn aber rueberschicken und ihm die Logindaten als verstecktes "Gepaeck" mitgeben
Und wenn ich erst die Daten mit dieser Methode rueberschicke und dann den Client per Redirect (welche Methode auch immer) hinterher, stehen ihm ja auf dem anderen Server nicht unbedingt die POST-Daten zur Verfuegung.

Oder stehe ich auf dem Schlauch und die POST-Methode impliziert, dass sowohl Client als auch Daten zum Ziel geschickt werden?

moses_78, vielen Dank dafuer. Curl ist auf meinem Webspace aktiviert, aber ich blicke in deinem Script ueberhaupt nicht durch. Macht es etwas aehnliches wie firewars' Link? Schaut zumindest aehnlich aus.

 

[firewars]

POSTe einfach sowohl Login- als auch die anderen POST-Daten, die du versenden willst. Dann ist das ja so, als wäre es ein Direktaufruf (ist es im Grunde auch), und du lässt einfach ausgeben, was die Kundenseite (kunde1.de) ausgibt. Dann brauchst du auch keine HTTP-HEAD-Weiterleitung.

Edit:

Oder stehe ich auf dem Schlauch und die POST-Methode impliziert, dass sowohl Client als auch Daten zum Ziel geschickt werden?

Nicht direkt, aber wenn du einfach die Rückgabe der Kundenseite (wie oben gesagt) ausgibst, ist es quasi das Selbe.

 

[Galanos]

Dann muss ich aber im Prinzip alle Anweisungen, Daten auf "kunde1.de" zu schreiben, in solch einen POST reinpacken, denn der Kunde navigiert ja nach wie vor auf meinem Server.
Und jedes fwrite(), move_uploaded_file() etc. so umstaendlich zu formulieren, kann auch nicht die Loesung sein.

Obwohl … Langsam komme ich dahinter: Eigentlich kann ja der Kunde sich auf meinem Server einloggen, von meinem Server den Cookie gesetzt bekommen, sobald er sich einloggt und, dadurch authentifiziert, Scripts auf meinem Server ausfuehren, die Scripts auf dem Kundenserver anweisen, Daten zu schreiben.
Hm – etwas komplizierter, als ich dachte, aber auch okay.
Ich denk mal drueber nach

 

[firewars]

Ja, ist in der Tat etwas fummelig, aber das liegt eher an den Umständen als an der technischen Ausführung

 

[moses_78]

moses, vielen Dank dafuer. Curl ist auf meinem Webspace aktiviert, aber ich blicke in deinem Script ueberhaupt nicht durch.

Da du dich ja nicht schlecht mit PHP auszukennen scheinst, hier der
betreffende Teil der Doku.

Noch 'ne kurze Erklärung:
- Im Array $formularfelder werden die Werte gespeichert, die an den Em-
pfänger geschickt werden sollen, als Arrayschlüssel der Name des Feldes,
als Inhalt eben der Wert....
- Mit curl_init("url") wird ein Curl-Handle erstellt, als Parameter ist eben
das Script anzugeben, dass die Werte entgegennehmen soll
- Die Curl-Option "CURLOPT_FOLLOWLOCATION" sorgt dafür, dass Umlei-
tungen gefolgt wird, was notwendig ist, weil Login-Seiten i.d.R nach Ein-
gabe eines korrekten Passworts ein Cokkie setzen, und den Browser zu
der Admin-Seite umleiten
- Die Option "CURLOPT_REFERER" kannst du dir sparen, "CURLOPT_USER-
AGENT" sicher auch
- curl_exec($handle) führt dann die HTTP-Anfrage aus, und gibt den Quell-
code der Seite zurück
- curl_getinfo($handle) gibt dann das in #3 bereits von mir erwähnte Array
zurück

Und ja, dass macht im Grunde das gleiche wie fsockopen(), welches es er-
möglich, HTTP-Requests händisch zu erstellen, und an den Server zu Sen-
den, nur ist die Variante mit Curl komfortabler.