@igelei: Lahmer Seitenaufbau wegen bug nach timeout wenn eingeloggt?

Beim Absenden eines
Postings prüft der zum einen die Session-ID, dann noch Time seit lastlogin
und ein wenig mehr.

Ist klar, das erklärt weshalb das mit dem Posten nach Ablauf des Timeouts nicht mehr klappt

Meine Vermutung bei deinem Phänomen (das ich auch schon
hatte) ist: Irgendwas kommt bei der Prüfung durcheinander oder beim
Schreiben des Cookies, die alte Session-ID ist in der DB verfallen, im
Cookie steht sie aber noch drin oder andersherum und man kommt deshalb
nicht weiter. Falls du das mal wieder hast, bitte mal probieren: Browser
schließen, Cookies löschen, neu einloggen und dann zu posten.

Ich weiß nicht ob es hier ein Mißvertständnis gibt: Des Aufbau aller DGF-Seiten ( ob Übersicht oder einzelne Postings ) ist bei ganz simplen Aufrufen unendlich langsam ( ich denke nicht NICHT einmal an Posten! )

Test folgt gleich.
Nach dem Absenden dieses Postings klicke ich wieder auf "beantworten" und gehe dann zum Tee-Trinken [[smile]]

Bis bald

J

... der Schreibberechtigung zusammen, dass unterschiedliche Dinge
miteinander verglichen werden. Beim Login gibt es eine Session-ID und ein
Cookie, bei dem die bei dir auf dem Rechner steht. Allerdings hab ic
nirgends gefunden, wie lange die Session-ID in der Datenbank gültig ist
und wo man deren Gültigkeitsdauer festlegen kann.

Das verwendete DBMS ist MS MySQL.

Ohne Aenderung des Parameters der Gueltigkeitsdauer der Session-ID wird beim generieren einer Session-ID grundsaetzlich dessen Factory-Default-Value angezogen.

Der Parameter heisst nach meiner jetzigen Stehgreif-Erinnerung Session-Boundary oder Session-Limit oder ein Mix beider Begriffe.

Du kannst den Factory-Default-Value der Session-Boundary auf 2 Wegen mit einem anderem Value "superseden":

1. Per expliziter Spezifizierung des Parameters Session-Boundary beim Generieren der DBMS-Session-ID;

2. Per expliziter Spezifizierung des Parameters Session-Boundary beim Starten (in der Start-Prozedur) des DBMS.

Ich wuerde Dir die Wahl der Loesung 2 anraten, weil das bereits beim DBMS-Start den Factory-Default-Value grundsaetzlich mit Deinem Value superseded.

Beim Absenden eines Postings prüft der zum einen die Session-ID, dann noch > Time seit lastlogin und ein wenig mehr.

Aha, was wird denn da im Server bei diesem Time Last Login geprueft? Woher hat er diese LL-Time (ggf. DBMS-Value?) und gegen was vergleicht er dabei, woher hat er letztere Vergleichswerte?

Meine Vermutung bei deinem Phänomen (das ich auch schon hatte) ist:
Irgendwas kommt bei der Prüfung durcheinander oder beim
Schreiben des Cookies, die alte Session-ID ist in der DB verfallen, im
Cookie steht sie aber noch drin oder andersherum und man kommt deshalb
nicht weiter.

Wie koennte "andersherum" (Session-ID DBMS ok, Cookie invalid) ueberhaupt zu Stande kommen (abgesehen vom manuellen Manipulieren in der Client-Maschine)?

Nee nee, es ist schon Deine erste Variante, die zutrifft, naemlich Session-ID DBMS invalid, weil die Session-Boundary schon zugeschlagen hat, das Cookie auf der Client-Maschine kann aber davon nix wissen und beinhaltet immer noch die Server-seitig invalidierte DBMS-Session-ID.

Falls du das mal wieder hast, bitte mal probieren: Browser
schließen, Cookies löschen, neu einloggen und dann zu posten.

JoBar hat seinen Test bereits gepostet und seinen Verbesserungsvorschlag abgegeben, den ich wie folgt ein wenig erweitere.

Wenn die DBMS-Session-ID invalid oder LL-TIME Threshold exceeded dann sofort

entweder Cookie auf der Client-Maschine loeschen

oder Cookie auf der Client-Maschine mit Dummy-DBMS-Session-ID modifizieren (z.B. Sess-ID 00000000 oder FFFFFFFF), diese Dummy-DBMS-Session-ID muss nach dem Eingang der Message auf der Server-Side abgefragt werden und als Message ohne Schreibberechtigung abgefackelt werden.

So richtig fällt mir dazu nicht ein, was man machen soll, die Prüfung
selber kann man aus Sicherheitsgründen nicht weglassen " />.

Ja logisch.

Na denn mal lous, Aermel hochkrempeln und nischt wie ran!

MfG
igelei

--
Gruss!
TD

Die StaSi tobt und Tassie kichert,
denn er ist Schaeuble abgesichert!