Andreas Korthaus: "echte" Login-Session mit HTTP?

Beitrag lesen

Hallo Harry!

Solange nicht zwei User gleichzeitig mit dem gleichen Benutzernamen angemeldet sind ... Spätestens dann bekommst Du nämlich Probleme, da sich dann zwei Benutzer die gleiche Session "teilen" müssen.

Das ist in meinem Fall egal, denn in der Session werden nur allgemeine Daten gespeichert, die sonst bei jedem Aufruf einer Seite neu aus TXT-Files und DB geholt werden müßten. Ich speichere da so Dinge wie Rechte des Useres, individuelle Menüstruktur als multidimensionalen Array, seine UserID, seinen Namen..., den Root-path, die Root-url..., das ganze gilt für alle Leute die sich mit diesem Usernamen einloggen könnten. Es kommt bisher leider auch einmal vor, dass ich die Session auch anderweitig brauche, da kann muß ich dann mal gucken wie ich das mache, entweder schreibe ich mir dafür was eigenes, oder ich uintegriere das irgendwie in meine Session, oder ich arbeite mit 2 echten Sessions - wenn das geht, und sonst muß ich das doch mit PHPSESSID machen. Aber das will ich nicht, denn die müßte ich wieder per Cookie oder URL übertragen.

Ja, kannst Du ... Bloß was ist, wenn der Timeout abläuft und der User nochwas vergessen hat? Einloggen kann er sich ja nicht mehr, weil er jedesmal wieder die abgelaufene Sessino zugewiesen bekommt.

Du hast das doch überall, web.de, gmx.de, die haben alle einen Timeout. Wenn der Useer was vergesen hat, dann muß er sich auch nochmal neu anmelden. Die Daten die der USer bearbeitet stehen ja nicht in der Session sondern in der Datenbank, in de Session stehen nur die oben genannten Werte, die dann halt noch einmal neu ermittelt werden müßten, aber besser so als auf jeder Seite neu!

? Wie kommst Du da drauf? So weit ich weiß schickt session_start() wenn möglich gleich ein Cookie an den Browser.

Das ist ja mein Trick! Cockies _und_ Trans-SID sind auf 0! Der Server schickt nichts und niemandem was! Wenn Du dir den Code nochmal anguckst wird die SessionID mit dem Wert von PHP_AUTH_USER belegt, und der wird über den HTTP_AUTH HEADER geschickt, das hat aber nichts mit Sessions zu tun, sondern halt mit http-authentifizierung!

  • Die "sessionID" wird _nirgendwo_ aus Versehen geloggt, das Passwort schon gar nicht

Sicher? Soweit ich weiß hat PHP eine Funktion (magic_irgendwas), die im Fall der Fälle (wenn das Cookie nicht angekommen ist) die SessionID an jeden Link anhängt. Dann kann die ID wie woanders auch ohne Probleme in den LogFiles hängen bleiben.

Wie gesagt habe ich alles augeschaltet, der Server sendet _nichts_! ich setze manuell die SessionID in jedem Script, und zwar nach Prüfung auf PHP_AUTH_USER!

Nur, daß sie in Deinem Fall ohne Passwort natürlich nicht mehr sooo nützlich ist (dafür steht aber ein mit Sicherheit gültiger Benutzername drin!)

Der steht nirgends. Den zu ermittlen geht nur über das belauschen des Traffics, aber wenn das möglich ist kannst Du dich über http nicht schützen, daher verwende ich zusätzlich https ;-)

Naja ... ich sehe keinen echten Vorteil darin, außer daß man einen gültigen Usernamen preisgibt. So eine 32-stellige (oder wieviel auch immer) ID dürfte nicht zu erraten sein. Wenn, dann nur über LogFiles oder durch (wie auch immer geartetes) Abhören der Verbindung ...

Wi egesagt, es geht _nur_ über das abhören, aber dann ist jeder Login-Schutz offen, egal ob über htaccess, oder eigenes Login-Formular... da bekommt er genau so alle Daten serviert, mit https denke ich sollte das hinreichend sicher sein.

Grüße
Andreas