WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

Du bist nicht angemeldet.

#1 09.10.2015 17:14:01

florian
Administrator

Timeout warner

I would be pleased if a kind of timeout warner as described here could be added to the next release.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#2 11.10.2015 08:02:21

norhei
Developer

Re: Timeout warner

You talking about a warner whith a visible timer ?? it would be extremely helpfull if you or someone else (Yetii?) can create a timer field that fits into the template design. I take care of bringing it to live.

Offline

#3 11.10.2015 09:22:51

florian
Administrator

Re: Timeout warner

I dont think Yetiie is active any longer, neither here nor at wb classic.
It does not have to be a countdown. I guess an alert which is popping up timely would be an enhancement already too.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#4 26.10.2016 16:41:28

florian
Administrator

Re: Timeout warner

Extrahiert aus einer angeregten Diskussion via PM...

norhei schrieb:

Habe noch ein Problem mit dem Anzeige Timer im BE
Wenn der nur Session Basiert ist , bleiben ja immer noch die FTANS in den Formularen , die nach einer bestimmten Zeit ungültig werden , sprich die Session kann auch noch genug Restzeit haben, aber das Forumlar produziert einen timeout, bzw.  "security alert".  Die Token laufen ja leider irgendwann ab.  Das gleiche gilt für die IDkeys in einigen Strukturen von DV .

Sprich der Timer bringt nicht wirklich etwas , da die Session sich ja bei anderen Seitenaufrufen verlängert , aber die Formulare ja ihre FTAN behalten.

Da bin ich grade ein wenig ratlos.

Was ich jetzt auf jeden Fall gemacht habe ist die Möglickeit gebaut , das Problem Session/Session Timer in einem Modul zu lösen das die Session Klasse einfach ersetzt/override.

stefanek schrieb:

Das Problem mit den Formularen und dem Ablauf der Session Zeit.
Man könnte Ajax verwenden, um alle paar minuten zu schauen, ob getippt wurde oder sonst was und wenn ja, wird der Time neu gesetzt.
Wäre da technisch was gegen einzuwenden?

norhei schrieb:

Das Problem ist , die Token sind selbst signiert, und Dementsprechend kann man die Zeit nicht manipulieren, weil Sie dann ungültig werden ...
Das ist ja der Sinn der Sache , das man die nicht manipulieren kann.

webbird schrieb:

    BC hat einen eigenen Sessiontimer, der auch das Re-Login ohne Datenverlust ermöglicht.

Gib mir mal einen Tip wo ich da schauen muss  ;-)


Ausserdem ist das Problem das manche Autoren z.B. Schreiben , dann einen Pause machen, und dann weiterarbeiten wollen.
Da wird dann nichts geklickt.

Grundsätzlich kann man die Session/Token  Laufzeit ja auf z.B. 8-9 Stunden Stellen , so das die einen Arbeitstag übersteht .
(Das sollte jetzt ja auch funktionieren) Wenn man ständig Pollen muß um die Session zu erhalten , kann man auch gleich die Laufzeit einfach hochsetzen .

Ich überlege grade ob man die FTAN Funktionalität so modifizieren kann, das die Post Variablen erhalten bleiben, dann könnte man das Form einfach nochmal anzeigen. Dafür denke ich muss aber das Formular auch etwas umgebaut werden, da manche ja kein Vernünftiges wieder anzeigen bei Fehlern unterstützen. ...


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#5 26.10.2016 16:41:42

florian
Administrator

Re: Timeout warner

webbird schrieb:

Ich erklär mal das Thema Sessions bzw. Timeouts, das dürfte das ein oder andere komische Verhalten erklären.

Zunächst mal muß man wissen, dass es zwei Arten von Timeouts gibt: Einmal serverseitig, wo man normalerweise bei Hostern keinen Einfluß drauf hat, und einmal CMS-seitig.

Der serverseitige Session Timeout hat die Bewandnis, dass der Garbage Collector hingehen und veraltete Sessiondateien löschen kann. Das ist natürlich gerade bei Servern, die unter Volllast stehen, von Bedeutung, weil die Sessiondateien zwar relativ klein sind, aber anzahlmäßig in die hunderttausende gehen können. Zudem ist es natürlich auch ein Sicherheitsfeature. Ob der GC allerdings _wirklich_ nach standardmäßig 24 Minuten (je nach Hoster auch mehr) hingeht und die Sessiondateien löscht, hängt von weiteren Faktoren ab.

CMS- bzw. WB(CE)-seitig wirkt sich der Session Timeout anders aus, nämlich auf den Cookie, der die Session-ID beinhaltet. Florian und ich hatten das Thema schon mal - während bei WB eine Session durchaus "endlos" laufen kann, wird bei LEPTON der Cookie beim Login einmalig hartcodiert mit einer Gültigkeitsdauer von 3 Stunden versehen. Warum das so ist, weiß ich nicht, Fakt ist, dass dieses einmal gesetzte "Verfalldatum" auch bei Aktivität im Backend nie aktualisiert wird. (Und dass LEPTON im Umkehrschluß jegliche Einstellungen im Backend ignoriert.) Bei LEPTON fliegt man also 3 Stunden nach der initialen Anmeldung gnadenlos aus dem BE raus, egal ob man grade was macht oder nicht. (Zumindest in der Version, auf der BC ursprünglich mal basierte. Wie das heute ist, weiß ich nicht.)

Setzt man nun die Sessiondauer in WB(CE) auf "endlos", kann man sich trotzdem nicht darauf verlassen, dass die Sessiondatei auf der Serverseite noch da ist, wenn man nach Stunden wieder aktiv wird. Theoretisch kann man in diesem Fall einfach eine neue Session erzeugen, allerdings mit ein paar Einschränkungen. Zum einen braucht man "irgendwoher" die Information, wer denn überhaupt angemeldet ist - also mindestens die UserID. Wenn die also im Cookie oder notfalls auch im Quellcode der aktuellen Seite nicht enthalten ist, war's das. Zum anderen können in der Session Daten gestanden haben, die nicht wiederherstellbar sind, z.B. Informationen, die Module reingeschrieben haben. Und zum Dritten ist das natürlich eine potentielle Sicherheitslücke, wenn man sich ohne Autorisierung darauf verläßt, dass noch immer der Mensch mit der ursprünglichen UserID vor der Tastatur sitzt. (Weshalb es auch weder in LEPTON noch in BC das "Smart Login" gibt, also den Haken "Angemeldet bleiben".)

BC geht nun den Weg, aus den Einstellungen des Servers die Sessionzeit auszulesen und damit die Cookie-Lebenszeit zu setzen. (Wir ignorieren derzeit also ebenfalls die Einstellung im Backend.) Bei jeder Aktion auf der Serverseite - also etwa Speichern einer Seite, Wechseln des BE-Bereichs etc. - wird diese Lebenszeit erneuert. (Also kein keepAlive durch Polling.) Auf der Clientseite läuft ein JavaScript Counter, der die verbleibende Sessionzeit anzeigt. 5 Minuten vor Ende der Lebensdauer wird die Schrift rot, kurz vorher auch der Hintergrund. Spielerei... angel

Ist nun die Sessionzeit abgelaufen, wird per AJAX ein reguläres Logout durchgeführt. Die aktuell geöffnete Seite wird mit einem Overlay versehen, einem (jQueryUI) Dialog, der ein erneutes Login erlaubt. Gibt man die korrekten Logindaten an, wird einfach nur der Dialog geschlossen - dahinter liegt stark abgedunkelt die Seite, auf der man vorher war. Dadurch gehen auch keine Daten verloren, auch dann nicht, wenn man stundenlang weg war. Einzige Einschränkung (die gehe ich mit BC2 an): Es kann sich theoretisch auch ein _anderer_ Benutzer anmelden als der, der vorher im BE war. Und wenn dieser dann nicht über die entsprechenden Rechte verfügt, gibt's spätestens beim Versuch, die Änderungen zu speichern, ein Problem plus potentiellem Datenverlust. Aufgrund dieses Vorgehens brauchen wir aber keine endlosen Sessionzeiten, weil ein Re-Login ohne Datenverlust möglich ist. Wir haben also einen Gewinn an Sicherheit - gleich in zweierlei Hinsicht - mit minimalem Komfortverlust.

Voraussetzung: Sowohl Login als auch Logout müssen per AJAX möglich sein. Könnte bei WBCE ein Problem sein. Bei BC war der Login zu dem Zeitpunkt ohnehin schon per AJAX umgesetzt, ich mußte nur den Logout anpassen. (AJAX funktioniert nur, wenn der Server eine ordentliche Antwort sendet. Eine komplette HTML-Seite ist zwar auch okay, man müßte aber per JS rausfiltern, ob der Login erfolgreich war oder nicht. Eine simple JSON-Antwort ist viel einfacher zu verarbeiten.)

Im BC-Forum habe ich eine Story gepostet, wo mir das Feature buchstäblich den A... gerettet hat, als wir nämlich mit 20 Leuten davor saßen und an einem Text gefeilt haben und plötzlich die Session abgelaufen war. Bei BC kam der Re-Login-Overlay - alle hatten Panik, dass die stundenlange Arbeit futsch war. Bei WB wäre das auch so gewesen. devil

@NorHei: Ich kann Dir den Code für BC2 geben, der ist allerdings auf Bootstrap Modal abgestimmt.

[== JavaScript ==]
function CATSecondsToTimeString(seconds) {
    return (new Date(seconds * 1000)).toUTCString().match(/(\d\d:\d\d:\d\d)/)[0];
}
function CATTimeStringToSecs(hms) {
    var a = hms.split(':'); // split it at the colons
    return (+a[0]) * 60 * 60 + (+a[1]) * 60 + (+a[2]);
}
function CATSessionSetTimer(sesstime,callback,elementid,warnclass)
{
    // set defaults
    if(typeof sesstime  == 'undefined') { sesstime  = 20;                        }
    if(typeof elementid == 'undefined') { var timer = $('div').appendTo('body'); }
    else                                { var timer = $(elementid);              }
    if(typeof warnclass == 'undefined') { warnclass = 'bg-danger';               }

    var warntime = sesstime * 0.2;

    timer.text(CATSecondsToTimeString(sesstime));
    timerId = setInterval(function() {
        var secs = CATTimeStringToSecs(timer.text())-1;
        if(secs <= warntime) { timer.parent().addClass(warnclass); }
        if(secs == 30)       { timer.css('color','#c00'); }
        if(secs == 0)        { clearInterval(timerId); callback(); }
        timer.text(CATSecondsToTimeString(secs));
    }, 1000);
}

Beschreibung hier: http://bc2.blackcat-cms.org/page/backen … cripts.php

[== JavaScript ==]
function CATSessionTimedOut()
{
    $('#bsSessionTimedOutDialog').modal('show');
    $('#bsSessionToFE').unbind('click').on('click',function(e) {
        e.preventDefault();
        window.location.replace(CAT_URL); // also removes history
    });
    $('button#bsSessionLogin').unbind('click').on('click',function(e) {
        $('div#login-error').text('').hide(); // make sure there is no old error
        var ufield = $('input.form-control.u').prop('id');
        var pfield = $('input.form-control.p').prop('id');
        var dates  = {
            'username_fieldname': $('input.form-control.u').prop('id'),
            'password_fieldname': $('input.form-control.p').prop('id'),
        };
        dates[ufield] = $('input.form-control.u').val();
        dates[pfield] = $('input.form-control.p').val();
        $.ajax({
            type    : 'POST',
            url     : CAT_ADMIN_URL+'/authenticate',
            dataType: 'json',
            data    : dates,
            success : function(data, status) {
                if(data.success === false)
                {
                    $('div#login-error').text(data.message).show();
                }
                else
                {
                    $('#bsSessionTimedOutDialog').modal('hide');
                    // reset session timer
                    CATSessionSetTimer(sess_time,CATSessionTimedOut,'span#sesstime');
                }
            }
        });
        e.preventDefault();
    });
}

Aufruf:

[== JavaScript ==]
CATSessionSetTimer(sess_time,CATSessionTimedOut,'span#sesstime');

Screenshots:
http://forum.blackcat-cms.org/viewtopic.php?f=11&t=582

Hier gibt's ein paar Infos zum GC:
http://www.mywebsolution.de/workshops/1 … ction.html

Hier gibt's übrigens einen Screenshot vom Session Timer.

http://forum.blackcat-cms.org/viewtopic … 413&p=2965

Das Popup X Sekunden vor Ablauf der Session gibt es allerdings nicht mehr.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#6 26.10.2016 16:43:24

florian
Administrator

Re: Timeout warner

norhei schrieb:

@webbird

Einige kurze Ergänzungen

- Bei einigen Hostern ist die Session Livetime fest eingebaut und kann nicht geändert werden , da hat man natürlich die AK =Arsch karte .

- Die Session Dateien kommen erst in die Garbage Collection wenn die Session abgelaufen ist, solange bleiben sie bestehen.
Sprich wenn man die Session Livetime auf 10 Stunden stellt können sie erst nach 10 Stunden möglicherweise weggeräumt werden.

-Möglicherweise, deswegen , weil die GC zufällig ausgelöst wird , Standardwert ist alle 100-1000 Seitenaufrufe.
Dadurch kann so eine Sessiondatei natürlich deutlich länger überleben.

- Bei Lepton spielt die Lebenszeit des Cookies im Browser mit rein, wie ich oben schon erwähnt hatte ist mir das bei WBCE auch passiert. Es ist ein Fehler von PHP  Das zwar die Lebenszeit der Session intern verlängert wird , aber nicht im Browser .
Wenn man dem Browsercookie also eine Lebenserwartung mitgibt

ini_set('session.cookie_lifetime', intval(WB_SECFORM_TIMEOUT)

, wird dieses nicht automatisch verlängert. 

Man muss also entweder  keine Livetime setzen, oder das Session Cookie bei jedem Aufruf erneuern.
Sprich mit setcookie () das dingen manuell refreshen sad 
Ich hatte mich für nicht setzen entschieden, aber einen eigenen internen Timer eingebaut der die Session nach der eingestellten Zeit auch zuverlässig beendet , also keine zufällige Verlängerung der Lebenszeit.
Dafür kann man es auf Wunsch einfach die Session auf eine beliebig lange zeit einstellen.

Setzt man nun die Sessiondauer in WB(CE) auf "endlos", kann man sich trotzdem nicht darauf verlassen, dass die Sessiondatei auf der Serverseite noch da ist, wenn man nach Stunden wieder aktiv wird.

Das sollte eigentlich nur noch passieren, wenn der Server ein fest eingestelltes Limit hat das man nicht überschreiten kann. 
Wie schon gesagt , am meisten Ärger macht der Cookie Bug durch den das Cookie einfach nach z.B. 3 Stunden weg ist und die Session nicht mehr wiederaufgenommen werden kann.


st nun die Sessionzeit abgelaufen, wird per AJAX ein reguläres Logout durchgeführt. Die aktuell geöffnete Seite wird mit einem Overlay versehen, einem (jQueryUI) Dialog, der ein erneutes Login erlaubt. Gibt man die korrekten Logindaten an, wird einfach nur der Dialog geschlossen - dahinter liegt stark abgedunkelt die Seite, auf der man vorher war. Dadurch gehen auch keine Daten verloren, auch dann nicht, wenn man stundenlang weg war. Einzige Einschränkung (die gehe ich mit BC2 an): Es kann sich theoretisch auch ein _anderer_ Benutzer anmelden als der, der vorher im BE war. Und wenn dieser dann nicht über die entsprechenden Rechte verfügt, gibt's spätestens beim Versuch, die Änderungen zu speichern, ein Problem plus potentiellem Datenverlust. Aufgrund dieses Vorgehens brauchen wir aber keine endlosen Sessionzeiten, weil ein Re-Login ohne Datenverlust möglich ist. Wir haben also einen Gewinn an Sicherheit - gleich in zweierlei Hinsicht - mit minimalem Komfortverlust.


Wie habt ihr das mit den Formtoken in Einklang gebracht , Die haben bei WB(CE) ja ein eigenes Timeout.  (und das ist ja im Moment das Problem. )

Voraussetzung: Sowohl Login als auch Logout müssen per AJAX möglich sein.

Da erinnerst Du mich an was !!! Das wollte ich auch noch reinmachen... Ist mit der Neuen Klasse nur ne Kleinigkeit .. hatte ich aber vergessen. 


Das Javascript werd ich mir heute Abend in ruhe zur Gemüte führen. 


@Florian , Kannst du die Langen texte eventuell in einen Thread verschieben /Kopieren ?


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#7 26.10.2016 17:51:31

webbird
Administrator

Re: Timeout warner

BC hat keine FTANs. cool
Wir benutzen CSRFMagic.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#8 26.10.2016 17:53:22

webbird
Administrator

Re: Timeout warner

IMHO gibt es nur einen Weg, alles in Einklang zu bringen und einigermaßen auf der sicheren Seite zu sein: Die Session Lifetime des Servers für alles zu verwenden, also sowohl für den Cookie als auch für die Tokens. Das würde im Umkehrschluß bedeuten, dass die Einstellung im BE wegfällt.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#9 26.10.2016 17:56:25

webbird
Administrator

Re: Timeout warner

Achso, zum Cookie: Ich setze nicht die PHP-Einstellung sondern gebe dem Cookie direkt seine Lifetime.

[== PHP ==]
    setcookie(
        session_name(),
        session_id(),
        time()+ini_get('session.gc_maxlifetime'),
        $cookie_settings["path"],
        $cookie_settings["domain"],
        (strtolower(substr($_SERVER['SERVER_PROTOCOL'], 0, 5)) === 'https'),
        true
    );

Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#10 26.10.2016 20:26:26

norhei
Developer

Re: Timeout warner

Trotzdem aktualisiert php das Session Cookie nicht obwohl es eigentlich sollte.


Bei CSRF magick:

* The default expiration time for tokens is two hours. If you expect your
      users to need longer to fill out forms, be sure to enable double
      submission when the token is invalid.

 

Die haben auch einen timeout ... Aber scheinbar eine Möglichlkeit Probleme da zu umgehen

Hatte auch schon gedacht CSRF Magick einzusetzen , aber ich habe die befürchtung das Module die FTAN einsetzen da nicht mit Harmonieren .
Deswegen hatte ich es in 1.2.x noch nicht eingebaut, da wir damit vermutlich etwas kaputt machen.

Aber eigentlich wäre das schon geil, Auf jeden Falll kann man es jetztmit 1.2.x als Modul einbauen und nutzen ..

Offline

#11 26.10.2016 20:28:26

norhei
Developer

Re: Timeout warner

Wenn nicht irgendwas schief gegangen ist , sollte im Moment die Einstelllung der Laufzeit funktionieren , natürlich nur wenn der Hoster das zuläst , aber meiner Erfahrung nach lassen das die meisten Hoster zu.

Offline

#12 27.10.2016 10:35:52

webbird
Administrator

Re: Timeout warner

Wir haben "leere" FTAN-Funktionen zur Rückwärtskompatibilität.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

#13 27.11.2016 21:18:36

florian
Administrator

Re: Timeout warner

Wie ist hier eigentlich der Stand? Ich hatte gerade mal wieder eine entnervte Kundenanfrage dazu und bin heute selbst beim Updaten des AOR mehrfach aus heiterem Himmel rausgeflogen. (Also nicht nach längerer Untätigkeit, sondern einfach so.)
Gibt es eigentlich irgend eine Möglichkeit, da ein Fehlerlog zu schreiben oder so?

Dieses Problem ist ein ganz, ganz großer Nachteil von WBCE, der dringend behoben werden muss.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#14 29.11.2016 18:49:02

grindmobil
Gast

Re: Timeout warner

Ja. Dass eine Session bei Inaktivität mal abläuft, das kennt man auch von woanders.

Aber dass sie zb beim Speichern nicht verlängert wird, das nervt wirklich. Das geht doch bei WB auch.

#15 29.11.2016 20:57:13

norhei
Developer

Re: Timeout warner

Das Sie beim speichern nicht mehr verlängert wird sollte bei 1.2.x nicht mehr auftreten .
Wenn der Server es unterstützt sollte sich die Session Laufzeit beliebig verlängern lassesn . Dann entsprechend langsam ab.

Das Problem war mitunter , das eine Cookie Lebenszeit gesetzt wurde. Diese wird aber dummerweise von PHP nicht verlängert. Da lief dann nicht die Session ab , sondern das Cookie im Browser. Die Cookies haben jetzt unbegrenzte Lebensdauer, und um die Session    livetime kümmert sich WBCE selber .

Man könnte jetzt die FTANs einfach ohne Timer laufen lassen aber das ist auch nicht so das Optimum. Bei CSRF magic kann man das meines Wissens nach  auch aktivieren , ist nur nicht standard mäßig aktiv.

Wie schon gesagt mein Hauptproblem ist das die Ftans nicht synchron miit den Refreshes von Anderen Seiten in Anderen Tabs auch aufgefrisht werden wie die Session das Wird,,,

Offline

#16 30.11.2016 08:23:34

florian
Administrator

Re: Timeout warner

Bitte nicht schlagen, aber wäre es möglich, für die 1.1 einen Patch bereitzustellen, um dieses Problem ohne die Notwendigkeit des Updates auf 1.2 zu lösen?


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#17 30.11.2016 10:09:16

grindbatzn
Gast

Re: Timeout warner

Eine grundsätzliche Frage:
Wäre es eigentlich möglich, das abzuschalten, dass für JEDEN Besucher eine Session angelegt wird? Ich weiß schon, das ist für manche Module nötig, aber wenn man auf zb Capchas verzichtet, dann braucht auch nicht jeder ein Cookie.

#18 30.11.2016 22:11:58

norhei
Developer

Re: Timeout warner

Das habe ich schon ein paar mal probiert :-(

Ist aber nicht sooo einfach , weil das so im Core hartverdrahtet war , teilweise noch ist ...

Ein erster Schritt war das ganze in ein Klasse auszulagern , die man einfach mal ersetzen kann.

Wenn jemand eine Konkrete Idee hat würde ich mich freuen das umzusetzen , ein Gedanke war Eventuell in der Page Datei explizit festzulegen das keine Session gestartet werden soll , oder in der DB .

Klar ein Shop geht nicht ohne Cookies und Session , alleine schon der Warenkorb  .. 
Module könnten in ihrer preinit.php eine Konstante setzen , die dann die Ausführung von Cookies erzwingt.
Leider wäre das unabhängig davon, ob das Modul geladen wird.

Die Session startet im moment lange bevor überhaupt klar ist , welche Module geladen werden.... eigentlich bevor überhaupt der eigentliche Core geladen wird.

Ist nicht so Trivial das zu ändern  ...

Offline

#19 30.11.2016 22:14:14

norhei
Developer

Re: Timeout warner

Als Seiten Einstellung vielleicht , aber dann muss man das für Jede Seite einzeln Setzen , das keine Session gestartet wird... muss nochmal nachdenken

Offline

#20 22.01.2017 10:38:29

florian
Administrator

Re: Timeout warner

Wir sind da etwas vom Thema abgekommen, ich wärme das nochmal auf.
1. Gibt es eine Möglichkeit, den Benutzer zu warnen, wenn er hinterrücks abgemeldet worden ist?
Wordpress kann das, bei Github kommt auch eine Warnung, wenn man z.B. zwei Github-Tabs offen hat und sich im anderen abgemeldet hat.

2. Wenn ja: Lässt sich so etwas noch in 1.1.x reinpatchen?

Wie gesagt, das ist so ziemlich der allergrößte Nachteil von WBCE, dass man da gerne mal rausgeschmissen wird und die Arbeit von Stunden im Nirvana verschwindet.

Beitrag geändert von florian (22.01.2017 10:40:31)


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#21 22.01.2017 21:40:12

norhei
Developer

Re: Timeout warner

Eines der Hauptprobleme ist bei WB, das es sich fast ausschließlich um Formulare mit einer save.php handelt.
Bei der Verwendung von Affenformularen  https://de.wikipedia.org/wiki/Affenformular wäre es zumindest sehr viel einfacher , da z.B. bei einem Abgelaufenen Token (FTAN) einfach wieder das Formular angezeigt würde , und man nur einfach nochmal absenden müsste.

Leider haben Wir das Problem das Token (FTAN) eigentlich eine begrenzte Laufzeit haben sollten. Auch die Klasse die BC (CSRF Magic)benutzt hat das als Option und ich finde es sollte besser eingeschaltet sein.

Aber derzeit ist , wie oben schon erwähnt , das Problem , das wir 2 Laufzeiten haben . Einmal das Sicherheitstoken und einmal die Session . Wobei die Session sich bei einem Seitenreload verlängern kann(Das sollte bei 1.2.x auch wieder richtig und unbegrenzt Funktionieren ), das Token nicht.   

Wobei mir beim nochmal aufgreifen der Materie , so der Gedenke gekommen ist , das es möglich sein sollte ,  den Ablauf  derToken an die Aktuellle Sessionid anzubinden anstatt an die Zeit .... 

Werde Das mal ausprobieren .
Es ist immer Gut sowas nach einer Weile nochmal zu hinterfragen. :-)

Offline

#22 22.01.2017 21:58:39

florian
Administrator

Re: Timeout warner

Ich hatte das vorhin, bevor ich das gepostet hatte, mit der 1.2a10 getestet. Einfach ne halbe Stunde einen tab mit einem wysiwig-abschnitt offen gelassen und dann auf speichern geklickt. Ergebnis Anmeldeseite. Es wäre schon unfassbar viel gewonnen, wenn man wenigstens irgendwo SEHEN würde, ob man noch drin ist oder nicht.

Nachtrag: also richtig rausgeflogen, nicht nur "Sicherheitsverletzung". Wobei die Sicherheitsverletzung allerdings genauso ärgerlich in Bezug auf den Verlust eingegebener Daten ist.

Beitrag geändert von florian (22.01.2017 22:00:43)


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#23 22.01.2017 22:38:40

norhei
Developer

Re: Timeout warner

Staune nicht schlecht ... sollte eigentlich bei einer Default installation bei 2 Stunden liegen ...

Muss ich mir vor Ort anschauen , wo kann ich schauen . Und Du schau bitte mal nach ob der Hoster dazu eine Einstellung bietet. session_livetime oder so .
Bitte auch mal den hoster Frage , ob die auf 30 Minuten  Fest eingestellt ist ?

Offline

#24 23.01.2017 08:24:54

florian
Administrator

Re: Timeout warner

Ist möglicherweise ähnlich gelagert:
https://forum.alfahosting.de/index.php? … n#post9303

Ich habe aber das Problem auch bei Seiten, die bei anderen Anbietern gehostet sind.


Code allein macht nicht glücklich. Jetzt spenden!

Offline

#25 23.01.2017 13:32:38

webbird
Administrator

Re: Timeout warner

In meiner Portable-Entwicklungsumgebung ist der Timeout sogar nur 20 Minuten. Die sind schnell mal um.


Ich habe eine Amazon-Wishlist. wink Oder spende an das Projekt.
Ich kann, wenn ich will, aber wer will, dass ich muss, kann mich mal

Offline

Fußzeile des Forums

up