Session Id über mehrere Domains bzw Subdomains

Hi leute,

ich möchte gerade ein Loginscript schreiben , jedoch kann ich es nicht testen. Es geht um folgendes:

Userxy geht auf eine Seite. Logt sich ein und kommt dann zur Serverauswahl. er wählt server aus und wird dabei auf eine Subdomain weitergeleitet zb s1.gamename.de. Meine Frage wäre nun wie kann ich die Session Id von einer Domain in die andere übergeben? Muss ich das überhaupt machen? oder bleibt die session id auf gamename.de und s1.gamename.de gleich? Ich will die alternative über URL nicht nutzen , ich finde es sieht schöner aus wenn in der url steht index.php?town=1234 anstatt index.php?town=1234&SID=123uikh12j3h usw.

Wie könnte ich das am besten noch local auf meinem PC simulieren das mit mehreren domains,bzw subdomains einfach ein link mit target="_blank" scheint nicht zu laufen, habe in beiden fällen gleiche session_id

Ich schätze ihr könnt mir helfen

MFG

Der ständigfragende Blacky:D

1. Du passt deine hosts-Datei an, und schreibst dort weitere, alternative Domains für deinen lokalen Loopback ein.

2. Du kannst das m.E. nur sinnvoll mit einem serverseitigen Login bzw. Tokenvalidierung lösen. Die SessionID selber kann jeder Server selber regeln, nur die Methode zum "gültigen User" ist unterschiedlich (bspw. nur durch einen Remotelogin).

hm... wie ich sehe, weis ich vieles noch nicht.

1. was meinste du mit hosts Datei anpassen? meinste httpd.conf bearbeiten?

2. wie setzt man eine Serverseiteige Tokenvalidierung um? Oder wie müsste ich das mit Remotelogin umsetzen?

MFg

EDIT: wegen den Domains, da habe ich was bei google gefunden wie man Virtual Hosts in XAMPP verwaltet. Ich schätze damit hat sich das mit Domains erledigt. Nun muss ich herausfinden wie das mit den Tokens funktioniert

Zu 1: http://lmgtfy.com/?q=hosts&l=1

Zu 2: Stichwort Server-zu-Server Requests, mit einer eigenen API. Nichts anderes machen auch die "standardisierten" Verfahren OAuth, OpenID im Hintergrund.

Hosts-Datei: /etc/hosts

Dein allgemeines Prolem ist das des Single Sign On oder kurz SSO. Lösungsansütze gibt es für einige...

http://de.wikipedia.org/wiki/Single_Sign-on

So long...

Maxx

...Yeah ich kann wikipedia quoten!!!

Oder du setzt dein Cookie einfach so, dass es auf der Hauptdomain liegt. So kommt es bei jeder Subdomain mit. Falls du dann noch mehrere Server hast, dann verwalte die Sessions zentral in einer Datenbank.

Original von Klaus

Oder du setzt dein Cookie einfach so, dass es auf der Hauptdomain liegt. So kommt es bei jeder Subdomain mit. Falls du dann noch mehrere Server hast, dann verwalte die Sessions zentral in einer Datenbank.

Zwingt dich direkt und für immer, das alle Systeme mit einer (Sub-)Domain von "deiner" domain.tld arbeiten. Kein anderer Spielname, keine andere TLD.. never ever. "Sind Sie sich wirklich sicher?" :)

Original von knalli

Original von Klaus

Oder du setzt dein Cookie einfach so, dass es auf der Hauptdomain liegt. So kommt es bei jeder Subdomain mit. Falls du dann noch mehrere Server hast, dann verwalte die Sessions zentral in einer Datenbank.

Zwingt dich direkt und für immer, das alle Systeme mit einer (Sub-)Domain von "deiner" domain.tld arbeiten. Kein anderer Spielname, keine andere TLD.. never ever. "Sind Sie sich wirklich sicher?" :)

Jedes Problem zu seiner Zeit. Und ja, man kann nicht mit einer Session zwischen mehreren Domains und dem gleichen Spiel wechseln. Aber wer will das? Es geht ja nur darum zwischen logischen Spielservern zu wechseln. nochmaliges einloggen geht ja immer noch.

Kommt auf die Anforderung an: Zum Beispiel sollen die Sessions vllt explizit nicht geshared werden - also völlig autonome Server. Aber gleiche Benutzer/Passwörter.

Hallo,

danke erstmal für die Ansätze, werde einige Stichworte googlen und mal nachsehen was für mich verständlich und logisch ist.

Nun allgemein was die Anforedungen sind und wie der Script aufgebaut ist:

Also ich habe eine Hauptseite mit regestrierung,wiki,login , etc.. und spiele seite auf der wird NUR das game script ausgeführt.

Aktuell wollte ich so vorgeben:

Ich habe ein "Webspace" und 2 und mehr Datenbanken. die eine Datenbank ist für die hauptpage gedacht und in dieser Datenbank sind login daten(session_id, username,pw,server). Bei der Regestrierung wird der benutzer einmal in die Hauptdatenbank eingetragen mit server namen und einmal in die spiel datenbank.

meine methode isLoggedIn ist simple , ich hole mir nur die id des users where session_id_aus_db = session_id().

die server auswahl findet auf der hauptseite statt. ich müsste also irgendwie eine nach außen unsichtbare id haben, welche jedoch für alle subdomains gleich ist. da aber ja alle subdomains auf ein und das selbe webspace zugreifen, dachte ich dass auch die session_id gleich bleibt.

oder man könnte es in eine datei auslagern und  und nicht mehr mit session_id sondern mit der datei vergleichen.

ist aber bis jetzt nur reine plannung , ich will erstmal eure meinung hören und dann einige sachen umsetzen.

Mit Freundlichen Grüßen,

Der nichtwissende Blacky:D

ok, nach stundenlangen googlen bin ich auf folgende überlegung gekommen:

http://cccpmik.wmw.cc/myPlan1.jpg

Erklärung:

User geht auf startseite und logt sich ein. Dabei werden die Logindaten mit den Werten aus der MainDB verglichen. Wenn die übereinstimmen, kommt man zur Serverauswahl , und zusätzlich wird die session_id als cookie abgespeichert, dabei wird geprüft auf welchen Servern der Benutzer bereits registriert ist, und auf den Servern wo der user registriert ist, deren Datenbanken werden Aktualisiert, sprich es wird der Cookie in deren Datenbanken eingetragen. Nun kann ich statt Session_id, den Cookie als loginvergleich verwenden.

Was haltet ihr von dieser Idee? Da ja Cookie browserabhängig ist, denke ich davon aus dass wenn sich ein tab fenster öffnet , bleibt der gleiche cookie.

Was mir ein wenig "Angst" macht, ist ja dass der Cookie auf dem CLient abgespeichert und man kann es manipulieren. Würde es denn da eine möglichkeit bestehen dass jemand den Cookie eines anderen Users einstellt? oder gibt es nie gleiche session_ids einer domain?

Hoffe ich habe hier nicht zu viele Fragen gestellt:D

MFG

Es kann nur mit dem gleichen Cookie und wahlweise der gleichen Datenbank (Sessiontabelle) oder eben internen serverseitigen Requests funktionieren.

Ansonsten kommt es bei dieser Konstellation unweigerlich zu deinem bereits erkannten Sicherheitsproblem.

Original von BlackScorp

ok, nach stundenlangen googlen bin ich auf folgende überlegung gekommen:

http://cccpmik.wmw.cc/myPlan1.jpg

Für schönere Mind-Maps:

http://freemind.sourceforge.net

Original von Bringer

Für schönere Mind-Maps:

http://freemind.sourceforge.net

Eak! Web. Cloud. Trendy. Multiuser. http://www.mindmeister.com :)

ok ich habe eine andere idee...

nach dem einloggen auf der startseite , habe ich die server auswahl:

http://server1.game.domain/index.php?site=login&password=123123&username=asdasd

damit ich mich quasi ein 2es mal einlogge. eine möglichkeit sich über die url anzumelden hatte ich sowieso vor , denn manchmal ist es praktischer eine url zu favoriten hinzuzufügen und man muss nicht ständig die daten ins eingabefeld eintippen.

und dann wäre da noch eine andere idee,

auf der startseite habe ich zu den loginfeldern, zusätzlich serverauswahl in einem select option feld. und je nach dem welchen server ich auswähle, werden dann an die server url die login daten gesendet.

was denkt ihr? ich schätze, es wäre sowas einfacher umzusetzen als meine erste idee, und es sollte auch mit mehreren domains funktionieren

MFG

Das Passwort in der URL. Ich glaub', mein Schwein pfeift!

ja aber natürlich nicht das passwort aus der datenbank, sondern das was der user eingegeben hat. also

Original von BlackScorp

ich finde es sieht schöner aus wenn in der url steht index.php?town=1234 anstatt index.php?town=1234&SID=123uikh12j3h usw.

wobei wir dann doch besser den "unschönen" ansatz nehmen sollten, damit das schwein von force nicht mehr pfeift

@scorp: mach dir das leben nicht unnötig schwer und setze den 2.vorschlag von knalli um. Lass den user wo auch imemr einloggen, nach success wird beim zielserver und  dem entsprechenden user ein token gesetzt (one time ticket), welches du bei weiterleitung natürlich mitübergibst. Sobald der zielserver den token erkennt, loggt er den benutzer automatisch ein  und managed die session. token sollte mind zeitlich befristet gültig sein, sonst wiederum kein stück besser als passwortübergabe in welche form auch immer

Original von BlackScorp

ja aber natürlich nicht das passwort aus der datenbank, sondern das was der user eingegeben hat.

Das würde doch gar keine Rolle spielen, in der Regel gibt der Spieler wohl das richtige Passwort ein, was? Zuerst einmal würde ich es als Benutzer absolut inakzeptabel finden, wenn meine Passwörter im Plaintext in irgendwelchen Accesslogs erscheinen würden, und außerdem könnte sich so jeder, der Zugang zum Rechner hat, auf dem ich mich angemeldet habe, meine Sitzung durch simples Aufrufen der URL aus dem Verlauf wiederherstellen.

Du merkst, das wird ein sicherheitstechnisches Desaster. Überleg' doch vorher lieber erst einmal, ob das, was du dir da vorstellst, wirklich notwendig ist.

ok ich habe nun was gemacht, was auch funktioniert.

ich loge mich auf der startseite ein und kriege folgende serverlinks:

Server1

auf der index.php der Subdomain wird folgendes gemacht:

verbinden mit der MainDB

Hole aus der MainDB die UserId WHERE session_id = $_GET['token']

Verbinde mit der SpielDB

Setze in der DB die session_id_in_DB = session_id() WHERE user_id = id aus der main.

Ab hier kann ich mit der Session_id der subdomain arbeiten und brauche kein token mehr.

Problem ist dabei, dass die User ID in der Main DB UND in der Spiele DB gleich sein MÜSSEN. aber darum mache ich mir später gedanken.

Danke schon mal für eure hilfen,

ill be back soon....

MFG BlackScorp

EDIT:

Hier mal das ergebnis eurer Tipps:

http://www.cruel-online.wmw.cc/

login: blackscorp
pw:123

Je nachdem wie du das System baust.. wenn du es richtig mit internen Aufrufen machst, dann ist sogar die User-ID theoretisch irrelevant. Theoretisch nur, weil in der Praxis will man ja doch auf dem Clientserver irgendeine Art der Verknüpfung haben oder alle anderen "Clientserver" vom "Masterserver" erfragen.

Terminologie (meine eigene)

• Masterserver: Verwaltung der Logins, Benutzerauthentifizierungsgegenstelle, Generierung der Tokens
• Clientserver: eigentliche Applikation, neue (gültige/eingeloggte User) Sessions nur über interne Requests durch Masterserver möglich

Die Alternative ist natürlich, dass der eigentliche Anwendungsserver die zentrale Datenbank abfragen muss. Je nach Szenario ist das sicherlich machbar und sinnvoll.

Bezgl. Passwörter und Urls: Ein No-GO! weil..

• GET-Parameter erscheinen ggf. in der Browserhistory (Peng)
• GET-Parameter erscheinen in der Serverlog (bspw. access.log)
• GET-Parameter sind sofort in allen Mitschnitten lesbar (instant)
• GET-Parameter werden aus Punkt 3 schnell von Tools getracked, evtl. sogar irgendwo im Cache und/oder sonstwo gespeichert (weiß ich jetzt, wie du das zu implementieren vor hattest)

Außerdem sollte man sich ein paar Grundregeln bewusst machen.. die kann man umgehen (gibt sicherlich Sonderfälle), aber es hat seinen Sinn, dass..

• reine Lesezugriffe, vor allem reine Commands (domain.tld/index?action=list) GET-Requests sind (Stichwort Cache, Bookmarks)
• reine Lesezugriffe, mit Filteroptionen sollten auch GET-Requests sein, es sei denn Punkt 4 tritt in Kraft (s.o.)
• Schreibzugriffe, also serverdatenveränderende, sollten prinzipiell POST (o.ä.) sein; es minimiert die Cachewahrscheinlichkeit (ich schrieb "minimiert"), es können keine Folgelinks generieren werden (vgl. ursprüngliches Problem von Wikipedia und noch manch altem Webtool, wo Suchagenten mit "?delete={id}"-Links ganze Wikis gelöscht haben; keine Logs
• GET-Urls sind _praktisch_ begrenzt, vor allem bei hochdynamischen Webanwendungen kann ich als Entwickler nicht immer festlegen und bestimmen, wie lange die endgültige URL wirklich wird