Hallo Philipp,
Ist es hierbei
wichtig, dass der Benutzer nur von *genau* einem Client auf deinen
Service zugreifen kann? - Wenn ja: vergiss es, leider. Es geht nicht.
Ein Computer lässt sich nicht eindeutig identifizieren, zumindest
nicht über HTTP, TCP/IP.Falls es nur darum geht, dass ein Benutzer während seiner Session
an einem Computer sitzen muss und den Service von keinem anderen
(über Kopieren der SessionId) Computer aus aufgerufen werden kann
(mit dem selben Login). Dann jain. Dies geht bedingt. Da HTTP selbst
Verbindungslos ist, kannst du niemals sicherstellen, dass der Request
von demselben Computer ausgelöst wurde. Wohl aber kannst du
sicherstellen, dass die Wahrscheinlichkeit klein ist, dass von zwei
Computern zur selben Zeit eine Anfrage kommen kann.
»»
Hmm, eigentlich soll eben immer nur ein User zur Zeit aktiv sein können. Ähhh, ja, hmm, wie sag ich das denn nun? Also sobald in meiner User-Tabelle ein Benutzer vorhanden ist, sprich eingeloggt ist, soll sich kein weiterer einloggen können und auch nicht das Login des ersten Benutzers verwenden dürfen (eben z.B. durch Kopieren der SessionID)
Dies funktioniert wie folgt:
Wenn sich ein Benutzer einloggt, wird eine SessionId generiert. Diese
ändert jedoch bei jedem Zugriff. Wenn der Benutzer also die aktuelle
SessionId (oder in diesem Zusammenhang wohl treffender: RequestId)
dem "Nachbarn" weitergibt, könnte dieser zwar weiter den Dienst
benutzen, aber du würdest dich selber aus dem Dienst "ausschliessen",
da mit jeder RequestId lediglich ein Request angefordert werden kann.
Sobald ein Service (PHP-Seite) durch eine RequestId angefordert
wurde, wird diese RequestId deaktiviert und die nächste RequestId
generiert (und ggf. an alle Links und Formulare reingeschrieben).Bei diesem Vorgehen gibt es jedoch grosse Probleme:
Man denke nur an die Situation, dass jemand auf die "Zurück"-Taste
des Browsers drückt und das Formular erneut absendet: Die im Formular
hardkodierte RequestId ist ja bereits deaktiviert und die Folge:
der User wird automatisch ausgeloggt...
Dein Vorschlag gefällt mir eigentlich sehr gut. Den Nachteil mit dem evtl. gedrückten zurück-Button kann ich verschmerzen, da es wie gesagt eh eine reine Webapplikation ist und es eigentlich auch keine 'Standard-Browser-Buttons' im Fenster gibt. Und wenn es jemand unbedingt ausprobieren will und übers Kontextmenü auf zurück klickt kann ich damit leben, wenn der Benutzer dann fliegt...
Wechselnde SessionID - man, da hätte ich auch selbst drauf kommen können... Schäm... Gibt es sonst noch andere Nachteile dieses Verfahrens? Mir fallen sonst eigentlich keine weiteren Nachteile auf...Aber das heißt nichts.. ;-)
Eine Mothode zur 100% erkennung würde mir noch einfallen: Wenn es per Javascript möglich wäre, die MAC-Adresse einer evtl. vorhandenen Netzwerkkarte auszulesen, würden wir der Sache mit der 100%-igen Identifizierung eines Clients näher kommen.. Ich ich glaube nicht, das ich so einfach die MAC-Adresse auslesen kann, sonst wäre das wohl schon längst gang und gäbe - von den Usern ohne Netzwerkkarte mal ganz abgesehen...
Vorab schonmal vielen vielen Dank!
Gruß
Mark