dethlef14

Hallo

Also ich shreibe gerade an einem Login-Script! Mein alter Script (mit Cookies) hatte den grossen Nachteil, dass sich einige wenige aber wichtige benutzer nicht einloggen konnten, da sie Cookies nicht erlauben.

Ich bin nun daran dies zu verbessern, der Script sollte folgende Funktionen haben

1. Login nur für diese Session, wenn die option "nächstesmal automatisches login" deaktiviert

2. Login nächstesmal automatisc falls option aktiviert

3. Login auch möglich falls Cookies deaktiviert, "automatischer Login" - dann "automatischer Login" Option immer? auf deaktiviert.


Was hab ich mir schon überlegt:
Hab hier schon einiges in der Suche gefunden und auch das Tutorial von Ben, gelesen, also keine Angst, das ist mir auch alles klar, aber...

Ich sehe nun 2 Möglichkeiten: ich könnte mit Sessions arbeiten, die für die 1. Anforderung optimal ist, für die 2. Option würde ich dann die Session-Laufdauer erhöhen. In der Session würde sowas wie $_SESSION['login']=true stehen. Für 3. könnte man etwas mit der PHPSESSID machen, da ich mir vorstellen könnte trans_id einzuschalten, oder alternativ dazu falls trans_id aus, von Hand die SESSID anzuhängen. Allerdings, sehe ich da irgendwie nicht, wie ich die SESSID verwenden kann, da die User-Daten in einer DB gespeichert sind und diese ja in keinem Zusammenhang mit der SESSID stehen...

Die zweite Möglichkeit die ich da sehe, ist diejenige mit Cookie und Session. Für 1. würde der Cookie einfach die Lebensdauer 0 haben, und somit 1 zu 1 die Session wiederspiegeln. für 2. Würde der Cookie eine längere Lebensdauer erhalten. Im Cookie würde irgend eine mit md5 verschlüsselte Kombination von User-name und Passwort stehen, die so auch in der db steht und verglichen würde. Wenn Vergleich erfolgreich, dann würde eine Session erzeugt mit Inhalt $_SESSION['login']=true, dies aus dem Grund, dass nicht bei jedem Klick dann eine Datenbankabfrage gestellt werden muss. Für 3. würde ich dann diesen md5 hash via get anhängen und halt bei jeder Seite einen Datenbank-aufruf zur pw-überprüfung machen.

Nun ja, kompliziert, aber ich sehe keinen besseren Weg. Wie würdet ihr soetwas lösen. Ich weiss dass die Get-Übergabe unschön oder gar unsicher ist, auch das verwenden von Cookies und Sessions ist unschön...

Wie würdet ihr sowas angehen, bin foh um Anregungen...

Daanke


Zweite Möglichkeit

Mister Ad

Flor1an

Also ich habe es so gelöst:

Ohne auto login: User loggt sich ein, Session wird erstellt, fertig.
Mit Autologin: User loggt sich ein, Session wird erstellt, Cookie wird erstellt. Verlässt der User die Seite wird die Session inaktiv bzw. wird dann nichtmehr verwendet. Kommt der User dass nächste mal wird automatisch gecheckt ob ein Cookie existiert, wenn ja wird eine Session erstellt und der User ist online.

Dadurch ist das Problem ob der User Cookies aktiviert oder nicht auch gelöst. Falls er sie deaktiviert hat halt autologin keine Funktion, aber ansich funktioniert alles über Sessions.

CC84

Zuerst einmal: Du kannst mit Sessions keine Dauerhafte Loginfunktion machen.

Wenn ich das so lese, hast du die Ãœberlegung hinter der Session auch noch nicht verstanden.
Eine Session teilt sich in 2 Teile. Zum einen die Sessionid, diese muss dir der Client jedesmal mitteilen, tut er dies nicht, ist die Session verloren, du kannst ihn also nicht mehr wieder erkennen.
2. Die Sessiondaten. Diese liegen auf dem Server, hier kannst du rein schreiben was du willst.

Um nun dafür zu sorgen, dass der User dir jedesmal die Session mitteilt, hast du 2 Wege.
1. Du verpasst ihm nen Keks mit seiner Sessionid, diese liest du jedesmal aus, schaust, ob die Session noch existiert und schaust, welche Daten in der Session drin stehen.
Vorteil dieser Methode: Du musst nicht an jeden Link und jedes Formular die SessionID anhängen.
Nachteil: Leute ohne Kekserlaubnis sind ausgesperrt.

2. Du hängst an jeden Link und jedes Forumlar seine SessionId an.
Vorteil: Kekse sind unnötig
Nachteil:
a)Eine Seite, die per Lesezeichen aufgerufen wird, kann niemals die aktuelle SessionID enthalten, damit wird er dabei niemals eingeloggt sein, selbst wenn er sich zuvor eingeloggt hat und eine SessionID bekommen hat, da diese seine aktuelle ID nicht übergeben wird.
b)Wenn er einen Link aus seiner Seite an jemand anderes übergibt, hängt da meist die SessionID mit dran, damit ist ohne zusätzliche Sicherheit der andere User nun mit den Rechten des Linksenders auf der Seite.

Vorteil der Session allgemein gegenüber Cookies. Wenn du Formulardaten in ner Session zwischen speicherst, dann kannst du dich auf deren unversehrtheit verlassen. Das ist leider bei Cookies nicht der Fall.

Das konstante Login bleibt aber auf jeden Fall an Cookies hängen, da Sessions immer irgendwann verfallen. Wie lange hängt von deiner PHP Config ab.

axo

das ist auch bei sessions nicht der fall. es ist zwar schwieriger, aber dennoch möglich, die session trotzdem zu manipulieren. vor dem anfassen der session-daten muss also trotzdem nochmal neu validiert werden.

grüße
axo

dethlef14

Razor: tönt sinnvoll und einfach, werde ich probieren! du hast also trans_id für die nicht-Keksler aktiviert so wie ich das verstehe, oder hängst du sie "von Hand" an? Ich gehe mal davon aus, dass es also eine 100% sichere Lösung hier nicht zu geben scheint, liesse mich vom Gegenteil aber gerne überzeugen...
btw. was speicherst du im Cookie, schlichtweg etwas Ã* la $_Cookie['login']=true?

CC84: Hmmm... Stimmt, hatte das mit der Session Id falsch verstanden, für mich war da ausser der Dauer kein unterschied zw. Cookies und Sessions. Vielen Dank für deine Ausführungen.


Vielen Dank für eure Hilfe!

CC84

Hast du da nen Artikel zu, wäre sehr interessant. Weil kann mir das gerade nicht so wirklich erklären, wie ein aussenstehender da Zugriff drauf bekommen sollte.

Basti

Hi.

session.use_trans_sid kannst du global aktivieren. Die Option klebt de SID nur an, wenn der Keks nicht gesetzt werden konnte. Allerdings musst du die SID bei Redirects (Location-Header) immer explizit anhängen.

Session-Daten lassen sich in der Regel nur über das Dateisystem manipulieren. Auf einigen Shared Hosts wird anschenend ein Zugriff aller Kunden auf die Daten in /tmp nicht unterbunden. Da du deine Session-Dateien aber natürlich eh an einem sicheren Ort speicherst ist das ja kein Kriterium. Ein anderer Punkt, ist dass mit register_globals = on Sessiondaten durch globale Variablen überschrieben werden können. Da gibt es sicherlich Möglichkeiten für Angreifer. Ist ja aber ebenso absurd, diese Option anzuschalten, wie seine Session-Dateien bei einem Massenhoster mit mod_php nach /tmp zu speichern.

Einen anderen Weg, wie jemand meine Session-Daten manipulieren könnte, sehe ich nicht - von groben Fehlern in der Anwendung natürlich abgesehen.

Basti

PS:
Achso, und in den Keks kommt natürlich der Benutzername und ein Wert, der sicherstellt, dass der Keks auch von dir gesetzt wurde und nicht vom Benutzer selbst erstellt wurde. Das Passwort würde ich hierzu nicht verwenden - unnötig, dass dieses bei jedem Request Klartext quer durchs Netz gereicht wird (es sei denn, du benutzt SSL natürlich). Besser also einen Wert, der nicht leicht zu erraten ist und den du z.B. bei jedem Request änderst und in die Datenbank legst. Damit verringerst du die Einbruchswahrscheinlich keit wenigstens ein bischen und zu Race Conditions sollte das nicht führen.

Flor1an

Also ich speicher in dem Cookie die Userid und dazu einen zufälligen String bzw. den md5 Hash davon. Dieser ist in der DB beim User gespeichert. So kann ich die Userid und diesen Hash mit der DB abgleichen.