WBCE CMS Forum

better-work

Mitglied

Re: Timeout im Backend

@webbird

Hallo Bianka,

wenn allerdings laufend Eingaben getätigt werden, müsste das doch vom System auch "weitergegeben" werden.
Dann nur nach 5 Minuten Inaktivität rauszufliegen, finde ich schon sehr merkwürdig...

Ich bin gerade aus dem WB SEO Tool geflogen, bei nur 5 Minuten Inaktivität, das war auch nicht so lustig....

---

Gruß Jörg

colinax

Developer

Re: Timeout im Backend

Oder dieses in den editor selber einbauen?

Ein globales CMS Feature in ein optionales Modul einbauen !!??

Dass ist keine gute Idee! Was machen dann die Benutzer von FCK, Editarea oder anderen Modulen die keinen Editor verwenden?

webbird

Administrator

Re: Timeout im Backend

wenn allerdings laufend Eingaben getätigt werden, müsste das doch vom System auch "weitergegeben" werden.
Dann nur nach 5 Minuten Inaktivität rauszufliegen, finde ich schon sehr merkwürdig...

Da kann ich nicht widersprechen, allerdings spielen da Mechanismen eine Rolle, die man nicht beeinflussen kann. In diesem Fall _könnte_ es sein, dass die Session-Datei auf dem Server gelöscht wurde. Zum einen ist es bekannt, dass der Garbage Collector des Apache Webservers ziemlich unberechenbar ist, zum anderen weiß man ja nie, was da sonst noch so passiert. (Angefangen von übereifrigen Admins über amoklaufende Cronjobs bis hin zu - was auch immer denkbar ist.)

Wie gesagt, ich habe das an anderer Stelle schon mal ausführlicher beschrieben, ich bin nur grad zu faul, Dir den Link zu suchen.

---

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

webbird

Administrator

Re: Timeout im Backend

Achso, Eingaben (Clientseite) allein reichen nicht, man muß den Server antriggern, also speichern.

---

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

florian

Administrator

Re: Timeout im Backend

Wie gesagt, ich habe das an anderer Stelle schon mal ausführlicher beschrieben, ich bin nur grad zu faul, Dir den Link zu suchen.

Hier: https://forum.wbce.org/viewtopic.php?pid=6583#p6583

---

Wir Benötigen: Cents, Euros... jetzt spenden!

better-work

Mitglied

Re: Timeout im Backend

@webbird

ich bin nur grad zu faul, Dir den Link zu suchen

Kein Problem... 

Ja, zum Thema: Wenn es halt nicht möglich ist, Okay.

Aber es ging beim alten WB, bei Lepton und ich denke mich daran zu erinnern auch bei Deinem System.
Dort wurde man nicht aus dem System geworfen, wenn es entsprechend eingestellt war.

P.S. Florian war schneller mit dem Link...

Beitrag geändert von better-work (08.06.2017 15:13:49)

---

Gruß Jörg

florian

Administrator

Re: Timeout im Backend

Es macht mich fertig, dass ich seit 2015 auf dem Thema herumreite und dieses Problem einfach nicht in den Griff zu bekommen ist.
(Die im oben verlinkten Thread erwähnte 1.2 ist die jetzige 2.0 DEV, da wurde das zwar nach beharrlichem Bitten endlich gefixt, aber dafür gibt es mit der Version 35 andere Probleme, und es ist nicht bekannt, ob sich das geänderte Session-Handling so ohne weiteres in den 1.x-Strang portieren lässt. Es ist zum Weinen.)

---

Wir Benötigen: Cents, Euros... jetzt spenden!

berny

Mitglied

Re: Timeout im Backend

Oder dieses in den editor selber einbauen?

Ein globales CMS Feature in ein optionales Modul einbauen !!??

Dass ist keine gute Idee! Was machen dann die Benutzer von FCK, Editarea oder anderen Modulen die keinen Editor verwenden?

Naja, das Problem tritt ja nur bei Schreiberein auf....

better-work

Mitglied

Re: Timeout im Backend

Es ist zum Weinen.)

Nicht doch, Alles wir gut...

Oder dieses in den editor selber einbauen?
...Naja, das Problem tritt ja nur bei Schreiberein auf....

Nein, ich bin ja zum Beispiel aus dem Backend im SEO Tool rausgeflogen.
Und da ist, zumindest meinem Verständnis nach, der CKE nicht aktiv.

Das Ganze müsste also unabhängig von einem Editor gelöst werden, da ja auch nicht vorhersehbar ist mit welchem oder ob sogar ggf. ohne Editor gearbeitet wird.

Was wäre eigentlich wenn das gesamte Backend in ein iframe geladen wird, und "außerhalb" alle 30 Sekunden ein PING, oder ähnliches erzeugt wird, der dann die Session Laufzeit automatisch verlängert. Jetzt mal so laienhaft nachgefragt...
Das hätte ja auch den Vorteil das nicht alle internen Vorgänge angepasst und umgestellt werden müssten!

Vor Laden des iframes müsste dann natürlich erst das erfolgreiche Login abgefragt werden.

---

Gruß Jörg

webbird

Administrator

Re: Timeout im Backend

Also eigentlich war der Aufwand bei BC gar nicht mal so hoch, ich bin mir nur nicht im Klaren, ob das daran lag, dass BC vieles (z.B. auch das Login) per AJAX macht, oder ob das bei WBCE auch relativ einfach umsetzbar ist. Müßte ich prüfen. Hab nur leider momentan überhaupt keine Zeit für sowas.

---

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

webbird

Administrator

Re: Timeout im Backend

Also was ich anbieten kann: Ich kann mir das auf Basis einer unveränderten WBCE 1.2 Portable anschauen, sobald ich Zeit dafür habe. Das kann aber durchaus August heißen.

---

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

bernd

Core-Team

Re: Timeout im Backend

Naja, das Problem tritt ja nur bei Schreiberein auf....

Eben nicht nur, es kann dich überall raushauen, o.k. beim Seiteninhalt erstellen (aka Schreiberei) ist es am ärgerlichsten, aber auch sonst nicht wirklich prickelnd ...

Was wäre eigentlich wenn das gesamte Backend in ein iframe geladen wird ...

Au-ja ... und in Media haben wir dann den iFrame im iFrame 

Klar kann man bei Schmerzen die durch ein gebrochenes Bein verursacht werden lediglich Schmerztabletten einwerfen, aber die Ursache der Schmerzen zu verarzten wäre bestimmt sinnvoller 

Ich hatte vor paar Wochen schon mal wegen der ganzen Mimik rumgespielt, komme aber irgendwie auf keinen grünen Zweig. Irgendwie habe ich den Eindruck als ob sich da irgendwelche Session- und Timing-Geschichten aus verschiedenen Teilen des Core gründlich in's Gehege kommen.
Schön wäre es natürlich, wenn jemand den großem Überblick hätte und klar sagen könnte was genau (und warum) da alles mitspielt. Was hat z.B. der ASP damit zu tun, der wohl auch (wenn aktiv) irgendwie eine Session startet (um nur mal einen Punkt zu nennen).

und es ist nicht bekannt, ob sich das geänderte Session-Handling so ohne weiteres in den 1.x-Strang portieren lässt

Das müßte sich doch irgendwie herausfinden lassen, wenn man denn ungefähr wüßte was und wo ...

---

... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...

webbird

Administrator

Re: Timeout im Backend

TEIL 1

Code aus LEPTON 1.3.1:

[== PHP ==]
	// Start a session
	if (!defined( 'SESSION_STARTED' )) {
		session_name( APP_NAME.'sessionid' );
		
		$cookie_settings = session_get_cookie_params();
		session_set_cookie_params(
			3*3600,		// three hours
			$cookie_settings["path"],
			$cookie_settings["domain"],
			(strtolower(substr($_SERVER['SERVER_PROTOCOL'], 0, 5)) === 'https'),	// secure-bool
			true	// http only
		);
		unset( $cookie_settings );

		session_start();
		define( 'SESSION_STARTED', true );
	}
	if (defined( 'ENABLED_ASP' ) && ENABLED_ASP && !isset ($_SESSION['session_started']))
		$_SESSION['session_started'] = time( );

Code aus WBCE 1.irgendwas

[== PHP ==]
// SESSION 
// WB_SECFORM_TIMEOUT we use this for now later we get seperate settings 
// Later we should get a nice session class instead of this improvised stuff.
ini_set('session.gc_maxlifetime', intval(WB_SECFORM_TIMEOUT));
ini_set('session.cookie_lifetime', intval(WB_SECFORM_TIMEOUT));
ini_set( 'session.cookie_httponly', 1 );
if(WB_PROTOCOLL=="https"){ 
    ini_set( 'session.cookie_secure', 1 );
}
session_name(APP_NAME . '-sid');
session_set_cookie_params(WB_SECFORM_TIMEOUT);

// Start a session
if (!defined('SESSION_STARTED')) {
    session_start();
    
    // this is used by only by installer in index.php and save.php we will remove this later
    define('SESSION_STARTED', true);
    
    // New way for check if session exists
    $_SESSION['WB']['SessionStarted']=true;
}

// make sure session never exeeds lifetime
$now=time();
if (isset($_SESSION['WB']['discard_after']) && $now > $_SESSION['WB']['discard_after']) {
    // this session has worn out its welcome; kill it and start a brand new one
    session_unset();
    session_destroy();
    session_start();
}
$_SESSION['WB']['discard_after'] = $now + WB_SECFORM_TIMEOUT;

if (defined('ENABLED_ASP') && ENABLED_ASP && !isset($_SESSION['session_started'])) {
    $_SESSION['session_started'] = time();
}

Code aus BC1:

[== PHP ==]
if (!defined('SESSION_STARTED'))
{
    session_name(APP_NAME.'sessionid');
	$cookie_settings = session_get_cookie_params();
	session_start();
    // extend the session lifetime on each action
    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
    );
    CAT_Registry::register('SESSION_STARTED', true, true);
}
if (defined('ENABLED_ASP') && ENABLED_ASP && !isset($_SESSION['session_started']))
    $_SESSION['session_started'] = time();

Jeweils initialize.php.

Der Code in BC1 zeichnet sich dadurch aus, dass die Cookie Lifetime mit der Session Lifetime gleichgesetzt wird. Eine eventuelle Einstellung wird nicht (mehr) berücksichtigt, weil man in etwa 99% aller Fälle keinen Einfluß auf die in der php.ini gesetzte gc_maxlifetime hat.

Der Code in LEPTON zeichnet sich dadurch aus, dass die Cookie Lifetime hart auf 3 Stunden gesetzt und nie mehr aktualisiert wird. Man fliegt aus L* also IMMER nach 3 Stunden raus. (Ob das für L* 2.x auch noch gilt weiß ich nicht.)

Der Code in WBCE beinhaltet noch irgendein Secure-mach-Session-tot-Geraffel, das sich meinem Verständnis entzieht, da ich die Hintergründe nicht kenne.

Beitrag geändert von webbird (08.06.2017 20:11:47)

---

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

webbird

Administrator

Re: Timeout im Backend

TEIL 2

Wie aktualisiere ich die Session?

Gar nicht. 

---

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

bernd

Core-Team

Re: Timeout im Backend

Dann wäre doch Lepton-Variante zusammen mit einer an prominenter Stelle platzierten "Sanduhr" doch schon mal gar nicht so blöd ?!?
Allerdings wird dann wohl wieder das

Der Code in WBCE beinhaltet noch irgendein Secure-mach-Session-tot-Geraffel, das sich meinem Verständnis entzieht, da ich die Hintergründe nicht kenne.

dazwischenfunken. Das ist genau das was ich oben meinte.

---

... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...

berny

Mitglied

Re: Timeout im Backend

Ok, der Gedanke mit dem editor war dann doch nicht weit genug gedacht.

Aber die Idee die Session im Hintergrund automatisch zu verlängern besteht immer noch...

Wie gesagt, der Nachteil dass sie unendlich bleiben würde wenn man sie nicht aktiv killt....

Beitrag geändert von berny (09.06.2017 07:08:41)

better-work

Mitglied

Re: Timeout im Backend

@webbird

Hallo Bianka,

also ich lobe jetzt hiermit schon einmal 100,00 Euro zur Problemlösung aus, vielleicht beteiligen sich noch mehr???

Das ich mich an mein Wort halte, ist Dir ja bekannt...

@berny

Aber die Idee die Session im Hintergrund automatisch zu verlängern besteht immer noch...
Wie gesagt, der Nachteil dass sie unendlich bleiben würde wenn man sie nicht aktiv killt....

Der Kill könnte mit der Benutzerabmeldung erfolgen.
Nachteil= Wenn der Benutzer sich nicht abmeldet, sondern einfach nur den Browser schließt.
Eigentlich alle Browser speichern per Default den Cookie solange bis er ungültig ist.

Hieraus ergibt sich ein neues Sicherheitsrisiko!

Beitrag geändert von better-work (09.06.2017 22:35:41)

---

Gruß Jörg

webbird

Administrator

Re: Timeout im Backend

Wenn ich ja wüßte, was ich da potenziell kaputt mache, würde ich das auch ganz ohne Geld machen. Ich fürchte halt nur, dieser ganze FTAN-Secure-hastenichgesehen-Kram...

---

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

better-work

Mitglied

Re: Timeout im Backend

...dann sollte sich Jemand™ mal dazu melden, der weiß, warum und wieso der gesamte Prozess völlig umgekrempelt wurde...

---

Gruß Jörg

berny

Mitglied

Re: Timeout im Backend

@webbird

Hallo Bianka,

also ich lobe jetzt hiermit schon einmal 100,00 Euro zur Problemlösung aus, vielleicht beteiligen sich noch mehr???

Das ich mich an mein Wort halte, ist Dir ja bekannt...

@berny

Aber die Idee die Session im Hintergrund automatisch zu verlängern besteht immer noch...
Wie gesagt, der Nachteil dass sie unendlich bleiben würde wenn man sie nicht aktiv killt....

Der Kill könnte mit der Benutzerabmeldung erfolgen.
Nachteil= Wenn der Benutzer sich nicht abmeldet, sondern einfach nur den Browser schließt.
Eigentlich alle Browser speichern per Default den Cookie solange bis er ungültig ist.

Hieraus ergibt sich ein neues Sicherheitsrisiko!

Wenn der Browser geschlossen wird gibt's auch keine Anfrage an den Server.. ..

Wo liegt das sicherheitsproblem eigentlich?
Wenn jemand die Session kapert?
Oder woanders?

webbird

Administrator

Re: Timeout im Backend

Normalerweise ist die Session ungültig, wenn der Browser geschlossen wird.

---

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

florian

Administrator

Re: Timeout im Backend

Ich habe norhei kontaktiert, er meldet sich dazu heute Abend/Nacht.

---

Wir Benötigen: Cents, Euros... jetzt spenden!

norhei

Developer

Re: Timeout im Backend

Also ... wenn ich mich recht entsinne sollten eigentlich die allermeisten der Probleme in der Dev Version schon erledigt sein.
Gehen wir das mal Punkt für Punkt durch.

1. Die Cookie Verwaltung des Browsers

Wenn der Benutzer alle Cookies löscht ist er ausgeloggt , wenn der Browser Automatisch beim schließen die Cookies Löscht ist er ausgeloggt.
Wenn Cookies beim Benutzer Browser in einen Timeout laufen  ist er ausgeloggt. Auf die ersten Beiden haben wir keinen Einfluss. Der Letzte Punkt kann ein PHP Problem sein siehe 2.

2. Der Browser läuft beim Benutzer in einen Timeout  und zwar immer nach z.B. 20 Minuten nach der Anmeldung , egal ob man zwischen drinn Seiten aufruft oder nicht.

Das liegt daran das PHP zu blöd ist das Session Cookie zu erneuern , kein Witz !
https://stackoverflow.com/questions/379 … ch-request

Erklärt das sehr schön. 

Zumindest Teilweise lässt sich das damit lösen das man den Session Teil in der /framework/initialize.php ein wenig ausräumt . 

// WB_SECFORM_TIMEOUT we use this for now later we get seperate settings 
// Later we should get a nice session class instead of this improvised stuff.
ini_set('session.gc_maxlifetime', WB_SECFORM_TIMEOUT);
ini_set( 'session.cookie_httponly', 1 );
if(WB_PROTOCOLL=="https"){ 
    ini_set( 'session.cookie_secure', 1 );
}
session_name(APP_NAME . '-sid');
session_set_cookie_params(WB_SECFORM_TIMEOUT);
// Start a session
if (!defined('SESSION_STARTED')) {
    session_start();
    
    // this is used by only by installer in index.php and save.php we will remove this later
    define('SESSION_STARTED', true);
    
    // New way for check if session exists
    $_SESSION['WB']['SessionStarted']=true;
}
// make sure session never exeeds lifetime
$now=time();
if (isset($_SESSION['WB']['discard_after']) && $now > $_SESSION['WB']['discard_after']) {
    // this session has worn out its welcome; kill it and start a brand new one
    session_unset();
    session_destroy();
    session_start();
}
$_SESSION['WB']['discard_after'] = $now + WB_SECFORM_TIMEOUT;
if (defined('ENABLED_ASP') && ENABLED_ASP && !isset($_SESSION['session_started'])) {
    $_SESSION['session_started'] = time();
}

Wird vereinfacht und es bleibt :

// SESSION 
// WB_SECFORM_TIMEOUT we use this for now later we get seperate settings 
// Later we should get a nice session class instead of this improvised stuff.
ini_set('session.gc_maxlifetime', intval(WB_SECFORM_TIMEOUT));
ini_set( 'session.cookie_httponly', 1 );
if(WB_PROTOCOLL=="https"){ 
    ini_set( 'session.cookie_secure', 1 );
}
session_name(APP_NAME . '-sid');
session_set_cookie_params(0);

// Start a session
if (!defined('SESSION_STARTED')) {
    session_start();
    
    // this is used by only by installer in index.php and save.php we will remove this later
    define('SESSION_STARTED', true);
    
    // New way for check if session exists
    $_SESSION['WB']['SessionStarted']=true;
}

Die Übeltäter hier waren mitunter

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

Damit wird den Cookies erst einmal eine Zeit aufgedrückt , aber wie schon gesagt PHP bekommts nicht automatisch hin das zu aktualisieren.
Der Code enthält auch noch den Versuch sicher zu stellen , das die Session Livetime Serverseitig nicht überschritten werden kann . Das war zwar eine Nette Idee, da aber das Ganze sowieso nicht wirklich gut funktioniert ... raus damit .   (In der Dev schon passiert)

Das bringt dann alles auf den Stand wie es bei WB auch ist .  Zusätzlich kann man wenn der Server das zulässt  in den Secureform Settings  die Konstante
WB_SECFORM_TIMEOUT ändern (Ja, die Token Laufzeit ändert im Moment auch die Session Laufzeit . Das damalige Release war gezeichnet von dem Druck  eine Sicherneits Lücke patchen zu müssen )

Bis auf diese Einstellmöglichkeit verhält sich der Code dann genau wie Classic. 

Theoretisch könnte man jetzt hingehen und das Cookie immer manuell aktualisieren, da aber auch das nicht alle unsere Probleme löst , wäre das nur ein Tropfen auf den heißen Stein.

Muss jetzt kurz weg , später gehts weiter ....

norhei

Developer

Re: Timeout im Backend

3. Sicherheitsverletzungen durch das Timeout der  Secureform Token .

Da diese Token ein Timeout besitzen würde ein halb ausgefülltes Formular auch aufgrund dieses Timeouts ungültig werden können . Vor allem wenn wie in 2.  das starre Timeout Limit der Session entfernt wird. Damit hätten wir hier die nächste Problemquelle . Gut man kann das Timeout ziemlich lang einstellen aber das ist sagen wir mal nicht wirklich elegant. Damit ist das Ganze sozusagen noch eine Altlast die wir am Hals haben. In der DEV Version hatte ich das so gelöst das die Token  nicht mehr an die Zeit sondern an die Session gebunden werden. Also statt er Zeit wird ein Secret verwendet das in der Session gespeichert wird .  Das wird so von so ziemlich allen großen CMS umgesetzt und zum Thema Sicherheit völlig ausreichend. (Wenn ein Angreifer die Session übernehmen kann ist CSRF ein absolut zweitrangiges Problem) . Mit dieser Änderung wird auch AJAX deutlich einfacher.

Dafür einfach mal in Git die Änderungen an der SecureForm.php im Framework anschauen.

4. Fest eingestellte 'session.gc_maxlifetime' im Server

Bei manchen Server ist es einfach nicht möglich die Session Livetime zu ändern. Mit einfachen Settings oder Tricks lässt sich da gar nichts machen.
Die einzige Möglichkeit ist eine eigene Session Verwaltung, dazu später mehr.   

5. PHP Bug bei mehreren Benutzern auf einem Server

Nicht selten kommt es vor , das etliche Benutzer sich einen Server teilen. Off ist es so das diese Benutzer sich ein /tmp/ Verzeichniss auf dem Server teilen 
und damit auch oft das Session Verzeichnis. Wenn ich jetzt bei mit eine sehr lange Session Laufzeit einstelle funktioniert alle so lange  wie die PHP gabage Collection nur von mir ausgelöst wird . Es werden dann alle Sessions die ihre Laufzeit überschritten haben entfernt und alles ist gut .  Wenn jetzt aber auf einem Anderen Account die gleiche Garbage Collection ausgelöst wird läuft diese mit der Session Laufzeit des anderen Accounts aber dummerweise über den gesamten Session Ordner und ALLE Sessions. Steht dieser Account auf den deutlich niederigeren Standardwerten des Servers werden Trotzdem alle Sessions gelöscht die diesen Wert überschreiten.    Schon hat man spontanen Sessionverlust obwohl eine Viel größere Zeit eingestellt ist.

Meiner Beobachtung nach haben recht viele shared Hosting Provider dieses Problem. Dummerweise kann man dagegen genau so viel tun wie gegen den Fest eingestellten  'session.gc_maxlifetime' im Server. Nämlich garnichts . Zusätzlich ließ sich das ganze auch mit der damaligen Classic Version genauso nachvolziehen.
Auch hier ist die einzige Möglichkeit eine eigene Session Verwaltung .

6. Verschiedene Timeouts + Javascript Timer

Mit all diesen verschiedenen Möglichkeiten die einen Session Timeout zur falschen Zeit  erzeugen können  ist es praktisch unmöglich einen Zuverlässigen Timer zu erstellen. Erst wenn die Session Zeiten richtig Synchronisiert sind, kann man einen Timer erstellen.

Was also tun ?

Wir könnten uns ein eigenes Session Verzeichnis einrichten , wenn der Server das zulässt. Aber das muss unbedingt außerhalb des Webroots liegen.
Wir können den Hoster auf die Probleme hinweisen, wenn der das Ändern kann und auch will ...

Aber die Einzige Lösung die das alles zuverlässig löst dürfte folgende sein:

Die meisten großen CMS benutzen aus diesem Grund einen eigenen Sessionhandler. Oft ist dieser direkt auch SQL basiert.
Damit hat man vollständige Kontrolle über alle Laufzeiten und kann nebenbei auch noch sehen wer alles grade Online ist.
Der Admin könnte sogar einzelne Benutzer bei Bedarf ausloggen.

Wer in die Dev Version mal reingeschaut hat dürfte feststellen , das eine solche Lösung dort schon implementiert ist.
Diese Lösung ist noch sehr einfach gehalten , aber sollte weitestgehend sauber funktionieren (beim Upgrade gab es da wohl noch ein Problem ?)   
Man könnte damit natürlich auch noch Benutzerstatistiken und mehr koppeln aber immer der Reihe nach. 

Fragen bitte :-)

Bin morgen  den 14.06.2017 komplett unterwegs, kann also maximal ein paar Worte vom Handy aus antworten. Ab Donnerstag kann ich dann wieder richtig Schreiben.

colinax

Developer

Re: Timeout im Backend

Hallo Norhei,

wie viel Aufwand wäre da nötig um das Ganze von der 2.x in die 1.x zu übernehmen?

Oder geht das garnicht, da es mit anderen Sachen wie z. B. FTAN zusammenhängt?

LG Colinax