Login für mehrere Projekte auf einer Website

Hiho,

da ich gerne für mehrere Projekte eine "Mutterseite" (im folgenden Seite A) (á la BigPoint) anlegen würde, hier ein paar Fragen zum Login und Registrieren.

Eigentlich is das ja ganz simpel :?,
man hat auf der "Tochterseite" (ich nenn sie mal Seite B) das Login-Formular,
die erhaltenen Daten schickt man A/login.php, z.b.  per fsockopen.

in A/login.php wird geprüft, ob Benutzername und passwort zusammenpassen und dann je nachdem "true" oder "false" oder ne Fehlermeldung zurückgegeben.

Mit dem Registrieren wärs im Prinzip genauso.

Evtl. könnte man vorher noch ein captcha-jpg vom Server A anfordern und einen code (mit session lässt sich das so schlecht machen, oder?), was beim senden der Reg-Daten verglichen wird, damit nicht jeder honk direkt an server A einen registrierungs-request schicken kann.

Bin ich damit auf dem Holzweg?

Irgendwelche Sicherheitslücken?

Sonst irgendwas, was man beachten müsste?

Also mal aus der Sicherheitsecke antwortend: Ich würde das nicht "A/login.php" nennen, sondern das extra in einen entsprechenden Service packen. Ja schon klar, natürlich auch eine PHP-Datei, aber die nur die spezielle Aufgabe für dein Login/Registrierungszeug hat. Die Schnittstelle kannst du wahlweise mit XML oder einem internen Format (ja/nein) definieren.

Zusätzlich würde ich aber noch ein Token - so eine Art Preshared Key - generieren. Ohne diesen Key würde dein Remote-Login/Register gar nicht erst arbeiten und jegliche Requests mit einem 403 o.ä. abweisen. Zeitgleich kannst du auch direkt tracken, wovon die Anfrage kommt - du musst dich nicht auf Referrer verlassen, da ist man uU dann ja verlassen.

Prinzipiell könnte man das sogar ohne PHP lösen, du musst ja nur einen Port auf dem Server aufmachen, der gem. deiner Spezifikation Daten annimmt und wieder ausgibt.

Alternative: Wenn es nur unterschiedliche Subdomains sind, dann kann man doch einfach das Cookie/die Session auf die gesamte Domain ausweiten?

Original von knalli

Also mal aus der Sicherheitsecke antwortend: Ich würde das nicht "A/login.php" nennen, sondern das extra in einen entsprechenden Service packen. Ja schon klar, natürlich auch eine PHP-Datei, aber die nur die spezielle Aufgabe für dein Login/Registrierungszeug hat.

Was meinst du genau mit "Service"? die login.php hätte ja auch nur diesen einen Sinn.

Zusätzlich würde ich aber noch ein Token - so eine Art Preshared Key - generieren. Ohne diesen Key würde dein Remote-Login/Register gar nicht erst arbeiten und jegliche Requests mit einem 403 o.ä. abweisen.

Also dass das Formular einen token (ist ja nichts anderes als ein code-String?) anfordert, der dann wieder mitgeschickt werden muss, richtig?
Bin nicht sehr bewandert in diesen Fachausdrücken

Es handelt sich schon um verschiedene Domains, und den Server direkt zu programmieren, davon hab ich null Ahnung. Mit PHP passt das schon ;)

Original von Blabbo

Original von knalli

Also mal aus der Sicherheitsecke antwortend: Ich würde das nicht "A/login.php" nennen, sondern das extra in einen entsprechenden Service packen. Ja schon klar, natürlich auch eine PHP-Datei, aber die nur die spezielle Aufgabe für dein Login/Registrierungszeug hat.

Was meinst du genau mit "Service"? die login.php hätte ja auch nur diesen einen Sinn.

Jaja, nur halt nicht "meinesuperdomain.de/login.php" wo jeder Depp das "Master-Login"-Script findet. Außerdem wollte ich klarstellen, das ich zwischen dem normalen Einloggen (was die "Super-Domain" vielleicht auch unterstützt) und dem Remote-Login unterscheiden würde.

Zusätzlich würde ich aber noch ein Token - so eine Art Preshared Key - generieren. Ohne diesen Key würde dein Remote-Login/Register gar nicht erst arbeiten und jegliche Requests mit einem 403 o.ä. abweisen.

Also dass das Formular einen token (ist ja nichts anderes als ein code-String?) anfordert, der dann wieder mitgeschickt werden muss, richtig?
Bin nicht sehr bewandert in diesen Fachausdrücken

Nein, wie ich sagte. Preshared. Vergleichsweise wie Google API Key, Wordpress API Key. Du erstellst beispielsweise mittels md5(rand()) einen Zufallstoken und speicherst ihn auf beiden Servern. Dabei stellt der Token die Identität klar - den Check auf Authentizität entfällt hier bzw. lässt sich in meinen Augen durch die Identität in diesem Szenario bereits klarstellen. Für höchste Sicherheit machst du das Remotelogin intern über HTTPS.. ka, was du da für Seiteninhalte hast ;)

Ein zusätzlicher Session-Token ist eigentlich nicht notwendig. Sowas würde ich für den Client einführen (auf Browserseite).

Es handelt sich schon um verschiedene Domains, [...]

Okay, schade ;)

Also ganz praktisch: Dein Login-Server bekommt eine Datei oder eine Tabelle in der Datenbank mit der Liste aller bekannten "Client-Login-Server", jeweils ein Tupel aus Identifier (Token) und Name. Vielleicht brauchst du auch noch weitere Informationen, z.B. ein Server darf nur bestimmte Accountdaten verifizieren lassen. Das läßt sich später auch erweitern..

Weitere Alternative die mir noch einfallen würde: LDAP-Server ;)

ja, ok, login.php war nur ein beispiel, wird sicher anders heissen :)

also, der Token ist also fest für jede Website, die sich anmelden darf, den wird man aber nicht unverschlüsselt übertragen, sonst ist er ja recht leicht auszulesen und somit wieder sinnlos?

Original von Blabbo

also, der Token ist also fest für jede Website, die sich anmelden darf, den wird man aber nicht unverschlüsselt übertragen, sonst ist er ja recht leicht auszulesen und somit wieder sinnlos?

Na ja, den müsste schon jemand auslesen der zwischen deinen beiden Servern sitzt. Also nicht ganz so einfach. Aber natürlich ist eine Verschlüsselung da sinnvoll. HTTPS wurde ja bereits angesprochen.

Mir fallen zwei (ähnliche Wege) ein:

Wenn man einen gemeinsamen DB-Server benutzt kann man eine Tabelle machen, in die ein Token und die Logindaten gespeichert werden. Der Token wird an die login.php übergeben, der Hauptserver guckt in der DB nach. Er gibt dann dementsprechend das Ergebnis zurück, der "Clientserver" löscht danach die Zeile in der DB.

Alternativ: Der Clientserver schickt einen Token an den Hauptserver (login.php), anhand dessen fragt dieser den Clientserver nach den Logindaten. (z.b. die logindaten temporär in einer DB oder einem Textfile, entweder DB auslesen oder die txt direkt abfragen [get http://login.mybg.de/#token#.txt])

Bei den Möglichkeiten ist es egal, ob ein Unbefugter an die URL der login.php kommt, oder gar den Token in die Hände bekommt.

Sicherer wird es, wenn man die Logindaten verschlüsselt und nur die beide Seiten den Schlüssel kennen. Pro Spiel würde ich einen anderen Schlüssel nehmen

PS: login.php ist hier natürlich nur symbolisch gemeint ;)

Original von Dunedan

Na ja, den müsste schon jemand auslesen der zwischen deinen beiden Servern sitzt. Also nicht ganz so einfach. Aber natürlich ist eine Verschlüsselung da sinnvoll. HTTPS wurde ja bereits angesprochen.

stimmt, Denkfehler meinerseits :)

@fornax: wollte schon unterschiedliche Datenbanken verwenden.

Bei der Alternativ-Methode wäre also der Trick, dass man die Login-Daten nicht schickt, sondern der Hauptserver sie vom Clientserver anfrägt, interessant.

Musste es ungefähr 10 mal lesen, bis ichs kapiert hab ;)

Vielen Dank allen Beteiligten für die Hilfe!