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.
Ich wuerde Dir die Wahl der Loesung 2 anraten, weil das bereits beim
DBMS-Start den Factory-Default-Value grundsaetzlich mit Deinem Value
superseded.

Sehr gut, danke.

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?

Unix-Timestamp beim login in die DB, vergleicht aktuell mit DB-Wert.

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.
Na denn mal lous, Aermel hochkrempeln und nischt wie ran!

Denke mal, den Standard-Wert in der DB hochsetzen sollte ausreichen. Muss mit Cheffe Kontakt aufnehmen und schauen, wo man den anpassen kann.

Danke für die Tips

MfG
igelei

... 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

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

So bin nach 45 Minuten wieder zurück

Abgeschickt um 17:08:10
Wilde Datentransfers, aber das Fenster verändert sich nicht
breche ab um 17:22

lösche Browser Cache
lösche alle Cookies aus 2008

Rufe das DGF erneu auf: jetzt blitzschneller Seitenaufbau

Also wenn es am unpassenden Cookie-Inhalt liegt ... wie wäre es mit direkten Löschen beim Timeout?
Und / oder gleich eine neue Session starten?
Oder der Experte soll sich den Kopf darüber zerbrechen [[smile]]

Falls es was zum Testen gibt poste es hier oder sende mir eine Email

Grüße

J

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

MfG
igelei

ich habe heute auf einen Artikel antworten wollen, bin aber unterbrochen worden ( dauerte vermutlich viel länger als die zulässige Zeit bis zum timeout ). Nach dem Absenden hatte ich ein daja vue.
Schon öfter war mir aufgefallen, daß manchmal beim Seitenaufbau des Gelben Forums kräftig Daten hin und her geschaufelt werden ( sagen zumindest die activity LEDs meines Routers ) aber am Monitor tut fast nichts. Nur die oberste Zeile "Das Gelbe Forum ..." wechselt sich ununterbrochen mit "Daten werden geladen .." ( oder so ähnlich ) ab.

Beim Absenden meiner Antwort ( nach dem time out! ) passierte genau das wieder.
Ich sicherte den Text, löschte das Fenster und eröffnete ein neues Antwort-Fenster: Wieder viel Activity, aber kein Bildaufbau.

Ich probierte es mit einer neuen Verbindung ( andere IP-Adresse ): unverändert.
Schließen aller DGF-Windows, dann Neu-Aufruf: unverändert
Löschen des IE-Caches: unverändert

Genervter Neu-Start des PCs: Normaler, schneller Bildaufbau.

Kann es sein, daß aufgrund eines Programm-Fehlers des vorangegangene timeout bei nachfolgenden Aufbauten von DGF-Fenstern etwas durcheinander gebracht wird?
Z.B. Endlos-Schleifen entstehen, die erst nach ihrem eigenen time out verlassen werden?

Nach einem einfachen Neustart (= tabula rasa ) funktioniert es ja wieder bestens.

Kannst Du mal bei Dir diesen Timeout beim Antworten provozieren und schauen was denn da so wild hin und her geschaufelt wird?

Happy Debugging [[smile]]

J