Zur Problemlösung ist schon genug geschrieben, aber zur Anwendungsphilosophie möchte ich noch was ergänzen:
Es gibt eine NETTE und eine BÖSE Art der Anwendung einer Login-Weitergabe:
- Die NETTE besteht darin, daß man einem Kunden den Zugang zu einer Reihe von zugangsbeschränkten Diensten vereinfachen möchte.
- Die BÖSE besteht darin, daß man SICH SELBST den Zugang zu den Konten des Kunden in den Diensten zu beschaffen.
Leider ist es so, daß der Mensch von Natur aus bösartig veranlagt ist und nur bei kräftiger Erziehung und Erfahrung dazu zu bewegen ist, nett zu sein. Die böse, betrügerische Seite überwiegt deshalb leider - auch im Internet und in Bezug auf Zugangsbeschränkungen.
WENN man nun ausnahmsweise zu den netten Leuten gehört und seine Kunden dazu anhält, ihre Logins für viele Dienste zu vereinheitlichen (was die Voraussetzung zur Funktion dieses Schemas ist), riskiert man eben AUCH, die Kunden zur Vertrauensseeligkeit gegenüber dem Rest der Welt anzuhalten, in dem reichlich bösartige Typen stecken.
Worauf ich hinaus will: Wenn so ein System eingerichtet wird, wäre es gut, die Nutzer auf den Ausnahmecharakter für die spezielle Anwendungsgruppe hinzuweisen und dazu anzuhalten, sowas nicht woanders nachzumachen.
Wenn es ohnehin ein in sich abgeschlossenes System ist (welches nur aus sonstigen organisatorischen Gründen auf mehrere Server verteilt ist), dürfte das aber eh kein Problem sein. Eventuell wäre dann sogar noch eine sinnvollere Alternative möglich: Wenn eine zentrale Datenbank benutzt wird, könnten der Login-Zustand zentral in der Datenbank verwaltet werden - unter Nutzung einer ebenfalls zentral verwalteten Sitzungs-ID.
Falls das Ding allerdings eine lose Sammlung fertiger Module (Foren/Organizer/Shops) ist, welche in sich nicht geändert werden sollen, wird wohl tatsächlich die Idee des Thread-Starters das sinnvollste sein.
Ich hoffe, das war jetzt nicht zu aufdrängelnd...