Sessionbasiertes Login - Ablauf der Session

[Blub]

Hallo!

Ich benutze ein Sessionbasiertes Loginsystem. Ähnlich wie hier beschrieben http://aktuell.de.selfhtml.org/artikel/php/loginsystem/

Funktioniert soweit auch sehr gut. Entsprechend der garbage collection Einstellungen wird die Session nach 30 Minuten Inaktivität gemüllt (bzw mit einer definierten Wahrscheinlichkeit).

Blöd ist jetzt, wenn ein User nach 30 Minuten großartig viel in div. Formularfelder einträgt, auf Absenden klickt, auf die Loginseite weitergeleitet wird weil die Session abgelaufen ist und die erfassten Daten im Nirvana landen.

Ich hätte gerne eine Lösung, die den User automatisch nach 30 Minuten abmeldet und auf die Loginseite leitet. Wie lässt sich das am Besten realisieren? Meine Idee wäre ein Javascript, dass bei jeden Seitenaufruf einen Countdown auslöst und nach 30 Minuten die Abmeldung durchführt oder eine entsprechende Meldung anzeigt. Kein Ahnung ob die Idee gut ist?

Bitte um Anregungen!
Danke!

[dedlfix]

Tach!

Ich hätte gerne eine Lösung, die den User automatisch nach 30 Minuten abmeldet und auf die Loginseite leitet. Wie lässt sich das am Besten realisieren? Meine Idee wäre ein Javascript, dass bei jeden Seitenaufruf einen Countdown auslöst und nach 30 Minuten die Abmeldung durchführt oder eine entsprechende Meldung anzeigt.

Was anderes als JavaScript läuft im Browser nicht und die Verbindung zum Server besteht nicht und kann auch nicht vom Server wieder aufgebaut werden. Ein ständiges Ajax-Polling oder Websockets für diesen Fall zu unterhalten, wäre mir zu viel des Guten.

Ansonsten wäre noch eine Möglichkeit, die Weiterleititis zu kurieren und das Login-Formular direkt in die jeweiligen Seiten zu integrieren. Dann kann dieses Formular auch im Hintergrund die POST-Daten durchschleifen, bis das eigentliche Formular wieder angezeigt werden kann.

dedlfix.

[Blub]

Was anderes als JavaScript läuft im Browser nicht und die Verbindung zum Server besteht nicht und kann auch nicht vom Server wieder aufgebaut werden. Ein ständiges Ajax-Polling oder Websockets für diesen Fall zu unterhalten, wäre mir zu viel des Guten.

Danke! Dann war mein Denkansatz vielleicht gar nicht so schlecht. Event. werde ich nach 29 Minuten eine Meldung anzeigen 'Sie werden nach 59, 58, 57... Sekunden automatisch abgemeldet' und wenn vom User keine Aktion folgt die Abmeldung nach 30 Minuten durchführen.

[dedlfix]

Tach!

Event. werde ich nach 29 Minuten eine Meldung anzeigen 'Sie werden nach 59, 58, 57... Sekunden automatisch abgemeldet' und wenn vom User keine Aktion folgt die Abmeldung nach 30 Minuten durchführen.

Das allein nützt dem Anwender noch nicht allzu sehr. Wenn er clever ist, öffnet er ein zweites Tab mit derselben Session, dann ist der Timer zurückgesetzt. Die erste Seite zählt zwar weiterhin fröhlich nach unten, aber seit dem zweiten Tab lügt sie.

Die meisten werden jedoch nicht den technischen Hintergrund haben, um auf solch eine Idee zu kommen. Denen könntest du mit einem Ajax-Aufruf-Link/Button/wasauchimmer einen Verlängerungsmechanismus anbieten - wenn es denn auf eine client-basierte Lösung hinauslaufen soll.

dedlfix.

[Blub]

Das allein nützt dem Anwender noch nicht allzu sehr. Wenn er clever ist, öffnet er ein zweites Tab mit derselben Session, dann ist der Timer zurückgesetzt. Die erste Seite zählt zwar weiterhin fröhlich nach unten, aber seit dem zweiten Tab lügt sie.

Oh Mann! Immer diese User ;-)

[Jörg Reinholz]

Ein ständiges Ajax-Polling oder Websockets für diesen Fall zu unterhalten, wäre mir zu viel des Guten.

Danke! Dann war mein Denkansatz vielleicht gar nicht so schlecht. Event. werde ich nach 29 Minuten eine Meldung anzeigen 'Sie werden nach 59, 58, 57... Sekunden automatisch abgemeldet' und wenn vom User keine Aktion folgt die Abmeldung nach 30 Minuten durchführen.

Eine oder zwei Minuten vor Ablauf der Frist (man denke an die Leute im Land, die sich vielleicht dazu per Modem oder ISDN einwählen müssen) von der Formularseite aus im Hintergrund mittels eines XMLHttpRequests die Session zu verlängern wäre mir nicht "zu viel des Guten". Ich glaube, die dadurch bewirkte Traffiksteigerung geht im statistischen Grundrauschen unter.

Dabei ließe sich ggf. auch ein anderes zeitliches Limit realisieren. Man könnte je nach Gustus client- server- oder sogar beidseitig prüfen, ob seit der letzten Verlängerung überhaupt eine Veränderung (Eingabe) erfolgte und nur in diesem Fall verlängern. Clientseitig sollte hier genügen. Das wieder in dem die eingetragenen Daten zu einem String aneinander gekettet werden und daraus clientseitig(!) sogar ein Hash (md5) gebildet wird, der mit dem vorherigen verglichen wird. Dann muss man sich nicht vorhalten lassen, ungefragt unabgesendete Daten zu speichern - was datenschutzrechlich durchaus bedenklich wäre. Zudem wird das bei großen Formularen Traffik und Speicher sparen.

Jörg Reinholz

[Siri]

Hallo,

Blöd ist jetzt, wenn ein User nach 30 Minuten großartig viel in div. Formularfelder einträgt, auf Absenden klickt, auf die Loginseite weitergeleitet wird weil die Session abgelaufen ist und die erfassten Daten im Nirvana landen.

Warum erhöhst du nicht den Session-Timeout, wenn ein Benutzer auf die Formularseite geht? Und nach dem Absenden setzt du sie wieder herunter.

Viele Grüße
Siri

[Blub]

Warum erhöhst du nicht den Session-Timeout, wenn ein Benutzer auf die Formularseite geht? Und nach dem Absenden setzt du sie wieder herunter.

Dann könnte ich den Timeout ja generell erhöhen oder verstehe ich dich jetzt falsch? Problematisch ist, dass sich kaum wer richtig abmeldet. Habe hier eine etwas schwierige Benutzergruppe ;-)

Danke und Grüße!

[Siri]

Hallo,

Problematisch ist, dass sich kaum wer richtig abmeldet. Habe hier eine etwas schwierige Benutzergruppe ;-)

Da hab ich deine Problematik auch nicht ganz richtig verstanden gehabt. Neuer Vorschlag.

Viele Grüße
Siri

[dedlfix]

Tach!

Warum erhöhst du nicht den Session-Timeout, wenn ein Benutzer auf die Formularseite geht? Und nach dem Absenden setzt du sie wieder herunter.

Das geht nicht so einfach, wie du vermutlich denkst und löst das Problem auch nicht wirklich. Wie hoch willst du es denn setzen? Wie lange darf zum Beispiel das Telefonat dauern, das den Ausfüllenden gestört hat?

Die PHP-Session-Einstellungen individuell zu ändern, bringt nichts. Jeder Script-Aufruf, der eine Session startet, triggert den Garbage Collector, der dann für alle Sesson-Dateien in demselben Session-Safe-Path aktiv wird - ungeachtet der anderen Anwendungen, die ebenfalls diesen Session-Safe-Path verwenden. (Schon deshalb empfiehlt es sich, für jede Anwendung einen eigenen Safe-Path zu konfigurieren.) Wenn eine Script-Instanz für sich einen Konfigurationswert ändert, gilt der nicht gleich für alle anderen Scriptinstanzen. Es ginge also nur, für alle Beteiligten ausreichend hoch gesetzte Konfigurationswerte zu verwenden und dann nach dem Session-Start individuell einen händischen Timeout nachzuprogrammieren, der dann eben beim Formular-Flag später zuschlägt. Aber wie gesagt, das verlagert im Grunde genommen nur den Datenverlust nach hinten.

dedlfix.

[Siri]

Hallo,

Warum erhöhst du nicht den Session-Timeout, wenn ein Benutzer auf die Formularseite geht? Und nach dem Absenden setzt du sie wieder herunter.

Das geht nicht so einfach, wie du vermutlich denkst

Scheint so... Bin mal vom Java-Session-Handling ausgegangen, das scheint bei PHP anders und aufwändiger.

Spricht irgendwas gegen einen iFrame mit 0px x 0px in dem sich eine Seite alle 60 Sekunden refresht? Dann kann das Telefonat dauern wie es will, solange die Formularseite geöffnet ist.

Viele Grüße
Siri

[dedlfix]

Tach!

Spricht irgendwas gegen einen iFrame mit 0px x 0px in dem sich eine Seite alle 60 Sekunden refresht? Dann kann das Telefonat dauern wie es will, solange die Formularseite geöffnet ist.

Das könnte gehen (solange der Iframe nicht den Fokus verschiebt oder anderweitig den Anwender beim Eintippen stört).

dedlfix.

[Siri]

Hallo,

Das könnte gehen (solange der Iframe nicht den Fokus verschiebt oder anderweitig den Anwender beim Eintippen stört).

Was meinst du mit "den Fokus verschiebt"?

Viele Grüße
Siri

[T-Rex]

Was meinst du mit "den Fokus verschiebt"?

Dedlfix kann für sich selbst sprechen, aber ich denke er meint damit den Focus der Eingabefelder.
Wenn der User beim Eingabefeld für seinen Namen steht und gerade versucht seinen Namen ein zu geben, gibt es im unsichtbaren Iframe einen Reload und schwups hat der Iframe den Focus und nicht das Eingabefeld. Der User müsste also wieder in das Eingabefeld klicken.

Gruß
Dedlfix's Kleinhirn
T-Rex

[Siri]

Hallo,

Wenn der User beim Eingabefeld für seinen Namen steht und gerade versucht seinen Namen ein zu geben, gibt es im unsichtbaren Iframe einen Reload und schwups hat der Iframe den Focus und nicht das Eingabefeld. Der User müsste also wieder in das Eingabefeld klicken.

Das wäre aber in diesem Fall schon das berühmte Pferd, dass direkt vor der Apotheke einen Bechanfall bekommt, oder? Bei einem iFrame von 0x0 Pixel und womöglich display: hidden.

Viele Grüße
Siri

[misterunknown]

Moin,

Blöd ist jetzt, wenn ein User nach 30 Minuten großartig viel in div. Formularfelder einträgt, auf Absenden klickt, auf die Loginseite weitergeleitet wird weil die Session abgelaufen ist und die erfassten Daten im Nirvana landen.

Ich würde vor dem Absenden des Formulars per AJAX prüfen, ob die Session noch existiert und andernfalls ein Login-Formular als Layer (oder wahlweise in einem neuen Fenster) anzeigen lassen. Dann kann der User eine neue Session aufbauen, ohne dass die Daten verloren gehen.

Grüße Marco

[Blub]

Ich würde vor dem Absenden des Formulars per AJAX prüfen, ob die Session noch existiert und andernfalls ein Login-Formular als Layer (oder wahlweise in einem neuen Fenster) anzeigen lassen. Dann kann der User eine neue Session aufbauen, ohne dass die Daten verloren gehen.

Daran habe ich auch schon gedacht. Die Sache hat sich aber ohnehin bald erledigt und ich will nicht mehr viel umbauen. Lösung wird eher quick and dirty werden. Das nächste mal dann halt richtig ;-)

Grüße

[Nik]

Ich würde vor dem Absenden des Formulars per AJAX prüfen, ob die Session noch existiert und andernfalls ein Login-Formular als Layer (oder wahlweise in einem neuen Fenster) anzeigen lassen. Dann kann der User eine neue Session aufbauen, ohne dass die Daten verloren gehen.

Grüße

Hi Marco,

interessanter Ansatz.

Kannst Du mir erklären (wiel ich genau dasselbe Problem wie der TO habe), wie Du das per Ajax vor Formularversand prüfen würdest?

Gruß, Nik

[misterunknown]

Moin,

interessanter Ansatz.

Ja :)

Kannst Du mir erklären (wiel ich genau dasselbe Problem wie der TO habe), wie Du das per Ajax vor Formularversand prüfen würdest?

Ich habe auf die Schnelle mal ein kleines Beispiel gebaut (mit Quelltext)... Bei mir (im Chrome) hat es gerade funktioniert, aber vielleicht ist es auch buggy (es ist Freitag und gleich Feierabend).

Hinweis: Das Skript gibt momentan zufällig entweder true oder false zurück. Diese Prüfung müsste natürlich so aussehen, dass man beispielsweise in der Session-Variable auf ein Login-Flag prüft oder auf den Usernamen != "" oder weiß der Geier^^

Weiteres am Dienstag, ich wünsche allen erholsame Pfingsten.

Grüße Marco

[Nik]

Ich habe auf die Schnelle mal ein kleines Beispiel gebaut (mit Quelltext)... Bei mir (im Chrome) hat es gerade funktioniert, aber vielleicht ist es auch buggy (es ist Freitag und gleich Feierabend).

Sagenhaft. Danke.

Verschwindet sofort in meinen "nützlichen Codeschnipseln"

Vielleicht könnte jemand Registriertes mal ein "nützliches Sternchen" setzen bitte.

Nik

[Nik]

Verschwindet sofort in meinen "nützlichen Codeschnipseln"

Achso.
Warum ich es nicht sofort selber einsetze?
Ich lasse standardmäßig bereits ein Ajax mitlaufen, daß dem User immer einen sogenannten Logoutbalken anzeigt. Dort kann er sich orientieren, wie lange er noch innerhalb seiner Session Zeit hat.
Anstatt ihn nach Ablauf auszulggen (wie bisher) kam mir die Idee, den Bildschirm einfach abzudunkeln und einen Login-Layer einzublenden.
Nachteil gegenüber Deiner Methode ist natürlich, daß da auch während des Tippens passieren kann.

Umgehen kann das Ganze ohnehin keiner, da nochmal serverseitig geprüft wird, ob der User eingeloggt ist.

Nik

[Nik]

Ich lasse standardmäßig bereits ein Ajax mitlaufen, daß dem User immer einen sogenannten Logoutbalken anzeigt. Dort kann er sich orientieren, wie lange er noch innerhalb seiner Session Zeit hat.
Anstatt ihn nach Ablauf auszulggen (wie bisher) kam mir die Idee, den Bildschirm einfach abzudunkeln und einen Login-Layer einzublenden.

Ich hab das gestern malumgesetzt.

Das ganze hat einen Schönheitsfehler, den ich gerne ausmerzen würde.

Wenn der User einmal seinen namen und Passwort eingegeben hat, danach weiterarnbeitet und anschließend wieder in den Logout läuft, wird der Login-Layer ein zweites Mal eingeblendet, aber Name und Passwort sind voreingetragen,obwohl im Layer selber in beiden Feldern value='' und autocomplete='off' notiert ist.

Klar, ich könnte die Felder auch nochmal per JS auf value='' setzen, aber das Ganze erscheint mir als Flickschusterei.

Kann mir jemand erklären, warum Name und Passwort voreingetragen sind?

Nik

[Jörg Reinholz]

Kann mir jemand erklären, warum Name und Passwort voreingetragen sind?

Ich vermute: Weil der Benutzer zuvor seinen Browser befahl: "Speichere diese Daten und hol Sie raus, wenn ich sie eintragen soll." Das geht mit einem Klick...

Wie man das verhindert? <input type="text" autocomplete="off" ...>

Wenn man ganz sicher gehen will vergibt man für die inputs zufällige Namen und speichert diese in einer session, holt diese dann wieder raus:

also statt:

<input type="text" name="username">

und dann:

... $_POST['username']

zu verarbeiten

wird jedes Mal ein neuer zufälliger Name gebildet

$_SESSION['username_inputname']="ZUFALLgjcwzcrjeg56354vghv";
und <input type="text" name="ZUFALLgjcwzcrjeg56354vghv">

und dann:

... $_POST[$_SESSION['username_inputname']]

verarbeitet. Dito für das Passwort.

Jörg Reinholz

[Mike]

Wie man das verhindert? <input type="text" autocomplete="off" ...>

Hab ich doch.

Wenn man ganz sicher gehen will vergibt man für die inputs zufällige Namen und speichert diese in einer session, holt diese dann wieder raus:

Klar.

Dennoch. Beim normnalen Login funktioniert das alles, nur bei dem Re-Login setzt der Browser User/Pass ein und das trotz value='' und autocomplete='off'.

Verstehe ich nicht.

Mike

[Jörg Reinholz]

Dennoch. Beim normnalen Login funktioniert das alles, nur bei dem Re-Login setzt der Browser User/Pass ein und das trotz value='' und autocomplete='off'.

Verstehe ich nicht.

Ist tatsächlich verwirrend. Hast Du irgendwas (vielleicht ein Framework?) verwendet, was ohne weitere Aktion Formulare generell automatisch als Affenformulare erzeugt?

Ein Blick in den Quelltext der resultierenden Webseite (also im Browser) könnte Auskunft geben. Es kann durchaus auch sein, dass der Browser-Cache Dir einen Streich spielt.

Jörg Reinholz

[Der Martin]

Hallo,

Ein Blick in den Quelltext der resultierenden Webseite (also im Browser) könnte Auskunft geben. Es kann durchaus auch sein, dass der Browser-Cache Dir einen Streich spielt.

ich könnte mir auch vorstellen, dass der Browser hier zwischen Autocomplete (Vervollständigen nach teilweiser Eingabe) und Autofill (automatisches Eintragen gespeicherter Formulardaten anhand der Feldnamen) unterscheidet.

Das erklärt aber nicht, warum Mike zweimal unterschiedliches Verhalten bekommt ...

Ciao,
 Martin

[Jörg Reinholz]

Das erklärt aber nicht, warum Mike zweimal unterschiedliches Verhalten bekommt ...

Ja, klar. Deshalb meinte ich ja das sei verwirrend, er solle also in den Quelltext schauen und dass ihm der Cache einen Streich spielen kann. Das sind jedenfalls die ersten, mir einfallenden Vermutungen.

Jörg Reinholz

[T-Rex]

Ich würde ein Cookie setzen.
Wenn das Formular gesendet wurde, guckst du einfach ob das Cookie gesetzt ist. Wenn ja ist der User wahrscheinlich noch eingeloggt (auch wenn die Session abgelaufen ist). An dieser Stelle könnte eine neue Session starten und der User wäre wieder "richtig" eingeloggt.
Wenn nein, wurde das Formular von einem nicht eingeloggten User geschickt und kann ignoriert werden.

Gruß
Krümmelmonster
T-Rex

[Jens Holzkämper]

Tach,

Ich würde ein Cookie setzen.

wo speicherst du das Geheimnis, dass du in den Cookie reinschreibst? Plus dem Problem, dass man für die Daten dann wieder ein komplett eigenes Sessionhandling-Konzept bauen muss; ich vermute zumindest, dass der Cookie nicht ewig gültig sein soll.

mfg
Woodfighter

[T-Rex]

wo speicherst du das Geheimnis, dass du in den Cookie reinschreibst?

What? Klingt ja fast so als ob da deine Kreditkartennummer drin steht :D.
Es muss etwas sein, dass den User eindeutig identifiziert. Sagen wir mal seine User id. Was sagst du, dann könnte sich jeder als dieser USer tarnen, wenn er das Cookie fälscht? Richtig, also muss noch irgendetwas einmaliges in das Cookie. Etwas das man nicht erraten könnte und das sich am besten noch ständig ändert. Wie wärs mit der Angabe des "last Login". Die Info speichert man in der Userdatenbank.

Plus dem Problem, dass man für die Daten dann wieder ein komplett eigenes Sessionhandling-Konzept bauen muss; ich vermute zumindest, dass der Cookie nicht ewig gültig sein soll.

Wieso nicht ewig? Mir drängt sich die Frage von Dedlfix auf "wie lange darf der User Telefonieren?". Wenn er seinen Computer einen Monat durchlaufen lässt und dann erst das Formular abschicken möchte...soll er doch.

Ein eigenes Sessionhandling? Das Problem verstehe ich nicht.

ich möchte hier keinen kompletten Code entwerfen nur im groben:

if( $_POST ) //--- Post daten prüfen  
if( send ) //--- Prüfen ob Formular gesendet wurde  
if( formular.valide() ) //--- PRüfen ob Formulardaten valide sind  
if( !$_SESSION['login'] == true )  
{  
    if( !$_COOKIE['userid'] )  
    {  
        //--- böser Hacker!  
        return false  
    }  
    $objUser = mysql_connect( "get user mit $_COOKIE['userid']" );  
    if(!$objUser->getLastLogin() == $_COOKIE['hash'] )  
    {  
        //--- böser Hacker!  
        return false;  
    }  
    login( $objUser );  
    save();  
} else {  
   save();  
}  

Sieht doch recht simple aus... verdammt wieso hab ich meinen Login nicht so simpel aufgebaut. Das scheiß ding läuft mit 4 Klassen die alle das gleiche machen hmpf...

Gruß
mit viel Code etwas kompensiernder
T-Rex

[Jens Holzkämper]

Tach,

wo speicherst du das Geheimnis, dass du in den Cookie reinschreibst?

What? Klingt ja fast so als ob da deine Kreditkartennummer drin steht :D.
Es muss etwas sein, dass den User eindeutig identifiziert. Sagen wir mal seine User id. Was sagst du, dann könnte sich jeder als dieser USer tarnen, wenn er das Cookie fälscht? Richtig, also muss noch irgendetwas einmaliges in das Cookie. Etwas das man nicht erraten könnte und das sich am besten noch ständig ändert. Wie wärs mit der Angabe des "last Login". Die Info speichert man in der Userdatenbank.

ein Angreifer braucht jetzt also nicht mehr das Passwort des Users, sondern nur noch den letzten Einlogzeitpunkt, das läßt sich doch schon sehr viel leichter Brute-Forcen oder vielleicht reicht es ja sogar nur die aufgerufenen URLs des Users zu haben (ok, Passworte und HTTP ohne S am Ende vertragen sich eh nicht), um den Zeitpunkt ziemlich gut abschätzen zu können. Ein Zufallsstring wäre da dann wohl doch besser.

Plus dem Problem, dass man für die Daten dann wieder ein komplett eigenes Sessionhandling-Konzept bauen muss; ich vermute zumindest, dass der Cookie nicht ewig gültig sein soll.

Wieso nicht ewig? Mir drängt sich die Frage von Dedlfix auf "wie lange darf der User Telefonieren?". Wenn er seinen Computer einen Monat durchlaufen lässt und dann erst das Formular abschicken möchte...soll er doch.

Dann kann ich auch gleich einfach Sessions serialisieren und den User nie ausloggen. Es macht halt durchaus Sinn, einer Authentifizierung nur einen gewissen Zeitrahmen lang zu trauen und du entwirst gerade ein System, bei dem sich der User nur ein einziges Mal authentifizeren muss und das obwohl die Lösung von ichbinich viel eleganter ist.

Ein eigenes Sessionhandling? Das Problem verstehe ich nicht.

Sessionhandling im Sinne von Daten, hier das gemeinsame Geheimnis, abspeichern und nach Ablauf eines vorgegebenen Zeitraums verwerfen.

if( formular.valide() ) //--- PRüfen ob Formulardaten valide sind
if( !$_SESSION['login'] == true )

  
Zumindest das würde ich aus Performancegründen umdrehen.  
  
mfg  
Woodfighter

[T-Rex]

ein Angreifer braucht jetzt also nicht mehr das Passwort des Users, sondern nur noch den letzten Einlogzeitpunkt, das läßt sich doch schon sehr viel leichter Brute-Forcen oder vielleicht reicht es ja sogar nur die aufgerufenen URLs des Users zu haben (ok, Passworte und HTTP ohne S am Ende vertragen sich eh nicht), um den Zeitpunkt ziemlich gut abschätzen zu können. Ein Zufallsstring wäre da dann wohl doch besser.

Hmpf... dann verschleier es doch ein wenig. bcrypt für das Datum oder du wandelst es in eine Zeichenkombination um. 1 Steht für a 2 für b, die punkte werden weggeschnitten... keine ahnung. Ein wenig kreativität braucht man dann schon noch.

und das obwohl die Lösung von ichbinich viel eleganter ist.

Joa sehr elegant. Der User sitzt vor dem Formular und macht 30 Minuten gar nichts. Dann klickt er auf absenden. Der Login ist abgelaufen, die daten werden in eine zweite Session geladen ein Loginscreen erscheint. Selbstverständlich füllt der User diesen SOFORT aus. Muss er ja auch, denn wenn er nochmal 30 Minuten wartet sind die Daten weg. Sehr elegant, muss man schon sagen ;).

Dann ist er halt länger eingeloggt, wo ist das Problem? Bei Facebook braucht man nur einmal den Haken setzen dass man länger eingeloggt bleiben möchte, dann ist man anscheinend das komplette Leben eingeloggt. Damit hatte ich noch nie Probleme, im Gegenteil. Hier bei selfhtml nervt es mich ständig mein Passwort ein geben zu müssen.

Gruß
"Cookie in Oreo umbennenen" Petition startender
T-Rex

[Jörg Reinholz]

Joa sehr elegant ... Der Login ist abgelaufen, die daten werden in eine zweite Session geladen ein Loginscreen erscheint. Selbstverständlich füllt der User diesen SOFORT aus. Muss er ja auch, denn wenn er nochmal 30 Minuten wartet sind die Daten weg. Sehr elegant, muss man schon sagen ;).

Hehe! Das klingt mir jetzt doch ein wenig nach einem alten Lied: "Wenn der Top aber nun ein Loch hat"

Jörg Reinholz

[ichbinich]

Hallo,

Blöd ist jetzt, wenn ein User nach 30 Minuten großartig viel in div. Formularfelder einträgt, auf Absenden klickt, auf die Loginseite weitergeleitet wird weil die Session abgelaufen ist und die erfassten Daten im Nirvana landen.

Dort müssen sie doch aber nicht landen. Was hindert dich daran, die gePOSTeten Daten in der Session zu speichern und nach dem Login wieder zur Fomularseite weiterzuleiten, wo sie dann bereits voreingetragen sind?

vg ichbinich

[Mike]

Dort müssen sie doch aber nicht landen. Was hindert dich daran, die gePOSTeten Daten in der Session zu speichern und nach dem Login wieder zur Fomularseite weiterzuleiten, wo sie dann bereits voreingetragen sind?

Das ist aber gar nicht einfach, wenn Du eine Seite mit 50 verschiedenen Formularen hast, die jeweils unterschiedliche Formularfelder haben.

Oder möchtest Du damit sagen, es gibt eine automatisierte Routine, die dann´auf alle Formulare anwendbar ist.

Mike

[Jens Holzkämper]

Tach,

Das ist aber gar nicht einfach, wenn Du eine Seite mit 50 verschiedenen Formularen hast, die jeweils unterschiedliche Formularfelder haben.

Oder möchtest Du damit sagen, es gibt eine automatisierte Routine, die dann´auf alle Formulare anwendbar ist.

speichere $_GET, $_POST und $_SERVER['PHP_SELF'] in der Session und prüfe am Anfang der Formulare, ob da was drin steht, um es dann an die passenden Funktionen zu übergeben.

mfg
Woodfighter

[Mike]

speichere $_GET, $_POST und $_SERVER['PHP_SELF'] in der Session und prüfe am Anfang der Formulare, ob da was drin steht, um es dann an die passenden Funktionen zu übergeben.

Klar, wenn ich ein Formular habe, ok.

Aber nicht in einem System mit z.b. 50 Formularen mit Dropdowns, Checkboxen, Inputfeldern, usw. Da sitzt Du Wochen dran, das alles zu implementieren.

Gruß, Mike

[Jörg Reinholz]

speichere $_GET, $_POST und $_SERVER['PHP_SELF'] in der Session und prüfe am Anfang der Formulare, ob da was drin steht, um es dann an die passenden Funktionen zu übergeben.

Aber nicht in einem System mit z.b. 50 Formularen mit Dropdowns, Checkboxen, Inputfeldern, usw. Da sitzt Du Wochen dran, das alles zu implementieren.

Wieso?

Gehen wir vom Fall aus, das die Antwort zu lange dauerte.

$_GET und $_POST sowie $_SERVER['PHP_SELF'] werden einfach in die Session gehangen. Z.B. als $_SESSION['POST'] und $_SESSION['GET'] sowie $_SESSION['SELF'].  Nach dem Re-Login wird zum verarbeitenden Skript (bekannt aus $_SERVER['SELF']) weiter geleitet. Das hat zu Prüfen ob $_GET und/oder $_POST in der Session abgelegt sind (wenn ja kann man es ja nach direkt nach $_GET aus $_SESSION['GET'] und $_POST aus $_SESSION['POST'] füllen, dann (mit unset()) $_SESSION['GET'] und $_SESSION['POST'] löschen .

Danach die Daten einfach genau so weiterverarbeiten wie bisher...

Das muss man nur einmal entwickeln und kann es ganz universell in 1, 10, 50 oder hundert Skripten mit require_once() einbauen.

Wochen dauert das nicht. Bei mir nicht und wohl auch nicht bei Jens Holzkämper.

Jörg Reinholz

[Mike]

Das muss man nur einmal entwickeln und kann es ganz universell in 1, 10, 50 oder hundert Skripten mit require_once() einbauen.

Wochen dauert das nicht. Bei mir nicht und wohl auch nicht bei Jens Holzkämper.

Universell einsetzen?

Steh ich denn momentan ganz auf dem Schlauch?

Also, die Daten aus POST, GET und SELF speichere ich eh ab, zwar nicht in einer Session, sondern in einer Log-Tabelle, aber davon mal abgesehen.

Ich weiß nicht, wie geartet soe ine Entwicklung aussehen soll, daß ich sie später per require_once() einbauen könnte?

Kannst Du mir ein kurzes Beispiel für ein Input- Text, Checkbox, Radio und Dropdown geben?

Ich wüßte nicht, wie ich das z.b. so universell formulieren könnte, so das es später auf alle Dropdowns meiner z.b. 50 Formulare passt.

Mike

[Jörg Reinholz]

Universell einsetzen?

Ja.

Steh ich denn momentan ganz auf dem Schlauch?

Wenn Du es so ausdrücken willst...

Also, die Daten aus POST, GET und SELF speichere ich eh ab, zwar nicht in einer Session, sondern in einer Log-Tabelle, aber davon mal abgesehen.

Das wirst Du dann erst mal ändern müssen...

Ich weiß nicht, wie geartet soe ine Entwicklung aussehen soll, daß ich sie später per require_once() einbauen könnte?

Kannst Du mir ein kurzes Beispiel für ein Input- Text, Checkbox, Radio und Dropdown geben?

Völlig irrelevent. Die eigentliche Verarbeitung der Daten bleibt völlig gleich, also genau so wie bisher!

Ich wüßte nicht, wie ich das z.b. so universell formulieren könnte, so das es später auf alle Dropdowns meiner z.b. 50 Formulare passt.

Wie gesagt: Das ist _völlig_ irrelevant, hier bleibt alles GENAU wie zuvor.

<script lang=phantasie>

Altes Skript:
-------------------
starte_session();
pruefe_anmeldung();
verarbeite_Daten();
-------------------

Dazu:
-----------------------------------------------------
if not pruefe_anmeldung();
-- kopiere Post-Daten nach session[post]
-- kopiere GET-Daten nach  session[get]
-- schreibe Skript-name nach session[self]
-- zeige LOGIN()
-- exit
else
-- if not erwartete Daten in Post oder GET
---- kopiere Daten aus session[post] nach POST-Daten
---- lösche session[post]
---- kopiere Daten aus session[get] nach GET-Daten
---- lösche session[get]
---- lösche session[self]
-- end if
end if
-----------------------------------------------------

Zusammen:
----------------------------------------------------
starte_session();
---include------------------------------------------
if not pruefe_anmeldung();
-- kopiere Post-Daten nach session[post]
-- kopiere GET-Daten nach  session[get]
-- schreibe Skript-name nach session[self]
-- zeige LOGIN ()
-- exit
else
-- if not erwartete Daten in Post oder GET
---- kopiere Daten aus session[post] nach POST-Daten
---- lösche session[post]
---- kopiere Daten aus session[get] nach GET-Daten
---- lösche session[get]
---- lösche session[self]
-- end if
end if
--- end include-------------------------------------
verarbeite_Daten(); // GENAU WIE BISHER
----------------------------------------------------

Anpassung des Login-Skriptes:

// bisher:
teste anmeldung()
// neu dazu:
if session[self]
-- leite zu http://server/skriptname aus session[self]
-- exit
end if
// bleibt:
// was auch immer bisher hier geschah

Jörg Reinholz

[Mike]

Ich wüßte nicht, wie ich das z.b. so universell formulieren könnte, so das es später auf alle Dropdowns meiner z.b. 50 Formulare passt.
Wie gesagt: Das ist _völlig_ irrelevant, hier bleibt alles GENAU wie zuvor.

<script lang=phantasie>

...

Hi,

achsooo. Jetzt verstehe ich das.

Du willst nicht den User zurück zur Formularseite leiten und dort die Werte in die Values setzen, sondern schickst seine Werte an das verarbeitende Script und er sieht dann nur noch die Ergebnisseite.
Ok, das ist tatsächlich universell und auch nicht viel Arbeit.

Mike

[Mike]

Also, die Daten aus POST, GET und SELF speichere ich eh ab, zwar nicht in einer Session, sondern in einer Log-Tabelle, aber davon mal abgesehen.
Das wirst Du dann erst mal ändern müssen...

Dann müßte ich aber 2 Sessions parallel nebenher laufen lassen können, stimmts?

Denn der Witz ist ja gerade, daß die erste Session "destroyed" wird und daher die Werte aus der (nun neuen 2. Session) benötigt werden.

Oder habe ich da wieder etwas mißverstanden?

Mike

[Jörg Reinholz]

Dann müßte ich aber 2 Sessions parallel nebenher laufen lassen können, stimmts?

Denn der Witz ist ja gerade, daß die erste Session "destroyed" wird und daher die Werte aus der (nun neuen 2. Session) benötigt werden.

Eine Session ist eine Session ist eine Session. Wenn die erste "destroyed" ist wird eben eine zweite aufgemacht. Wesentlich ist nur, dass diese Session die Formulardaten bekommt. Wenn jetzt das Re-Login erfolgt, so bleibt es die zweite Session mit dem Formulardaten, nur ist eben im hash (Sessions werden als hash abgebildet) dann auch der Hinweis enthalten, dass der Benutzer angemeldet ist. Das erfolgt in der Regel dadurch, dass man die UID und/oder den Benutzername hinterlegt.

Aus dem Grund hatte ich auch vorgesehen, die übertragenen Formulardaten zu löschen.

Jörg Reinholz

[Mike]

Eine Session ist eine Session ist eine Session. Wenn die erste "destroyed" ist wird eben eine zweite aufgemacht. Wesentlich ist nur, dass diese Session die Formulardaten bekommt. Wenn jetzt das Re-Login erfolgt, so bleibt es die zweite Session mit dem Formulardaten, nur ist eben im hash (Sessions werden als hash abgebildet) dann auch der Hinweis enthalten, dass der Benutzer angemeldet ist. Das erfolgt in der Regel dadurch, dass man die UID und/oder den Benutzername hinterlegt.

Hi Jörg,

Ich hinterlege den Benutzernamen in meinen Sessions.

Aus dem Grund hatte ich auch vorgesehen, die übertragenen Formulardaten zu löschen.

Ok.

Ich sitz grad an einer anderen Sache, werde mich aber in den nächsten Tagen wieder hiermit beschäftigen. Meine erst-vorgesehene Lösung funktioniert zwar inzwischen tadellos, aber ich denke, Deine Lösung gefällt mir noch nen Tacken besser.

Tust Du mir nen Gefallen? um Doppelpostings zu vermeiden, kannst Du den Thread noch 'n paar Tage im Auge behalten? Ich würd gerne nochmal auf Deine Hilfe zurück kommen, falls ich sie benötige.

Gruß, Mike

[Jörg Reinholz]

Tust Du mir nen Gefallen? um Doppelpostings zu vermeiden, kannst Du den Thread noch 'n paar Tage im Auge behalten?

Das ist hier für die meisten der Antwortenden das Standard-Verhalten. Tipp: Sende die weiteren Fragen nicht direkt ab, gehe statt dessen in die Vorschau und Ändere dann den Betreff aussagekräftig ab. Dann sieht man sofort, dass ich noch Fragen ergeben haben.

Jörg Reinholz

[Mike]

Vorschau und Ändere dann den Betreff aussagekräftig ab. Dann sieht man sofort, dass ich noch Fragen ergeben haben.

Hi Jörg,
ja, gerne.
Mike

[dedlfix]

Tach!

speichere $_GET, $_POST und $_SERVER['PHP_SELF'] in der Session und prüfe am Anfang der Formulare, ob da was drin steht, um es dann an die passenden Funktionen zu übergeben.
Klar, wenn ich ein Formular habe, ok.
Aber nicht in einem System mit z.b. 50 Formularen mit Dropdowns, Checkboxen, Inputfeldern, usw. Da sitzt Du Wochen dran, das alles zu implementieren.

Mit einem Absenden kann immer nur ein Satz Formulardaten mitgesendet werden, nicht 50. Aber darauf kommt es nicht an, weil man ja, wie schon erwähnt, GET und POST schön handlich in einem Zug in die Session schreiben kann. Die Daten nach dem Login wieder in die passenden Felder zu schreiben, sollte wegen der Benutzerfreundlichkeit sowieso bereits erledigt sein, weil man das für das Prüfen mit anschließeneder Wiedervorlage bei Fehlern benötigt (Affenformular). 50 Formulare ergeben gegenüber einem Formular keinen großartigen Mehraufwand zu der auch anderweitig benötigten Funktionalität.

dedlfix.