Project

General

Profile

Actions

Bug #9898

open

Formular trotz Timeout gespeichert

Added by Nicola Chiapolini about 4 years ago. Updated about 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Benjamin Baer
Target version:
-
Start date:
17.01.2020
Due date:
% Done:

0%

Estimated time:
Discuss:
Prio Planung:
Vote:

Description

In den letzten Monaten ist es schon zwei mal vorgekommen, dass ein Formular gespeichert wurde, obwohl das Frontend-Login scheinbar abgelaufen war. Scheinbar, weil ich das nur aus Hinweisen schliesse: zum Einen wurde der Report auf der "Forward URL" des Formulars nicht ausgeführt (der feuert ein weiteres UPDATE query und sendet ein E-Mail) und zum Anderen zeigt das sql.log einen neuen Login direkt nach dem speichern (vgl. unten)

Ich verstehe aber auch nicht wirklich, weshalb das Frontend-Login abläuft. Die Typo3 Config ist

[FE][lifetime] = 0
[FE][sessionDataLifetime] = 86400
[FE][permalogin] = 0

und auch session.gc_maxlifetime=86400

das annonymisierte SQL Log:

[2020.01.16 11:45:59 +0100][130.60.95.112][FE:SHORT,Page:84,tt:171,level:40.10][UPDATE typo3_studentadmin.fe_users SET usergroup='4,1' WHERE username='SHORT' AND deleted='0' LIMIT 1]
[2020.01.16 11:45:59 +0100][130.60.95.112][FE:SHORT,Page:84,tt:171,level:40.10][Affected rows: 1]
[2020.01.16 11:48:06 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][INSERT INTO Dirty (`sip`, `tableName`, `recordId`, `expire`, `recordHashMd5`, `feUser`, `qfqUserSessionCookie`, `dirtyMode`, `remoteAddress`, `created`) VALUES ( '5e203efef41d2','phd_graduation','400','2020-01-16 12:03:05','c4472b22659d70b6861455db23ca999c','SHORT','s6kua7c734irt5f2mhsi7m1k7t','exclusive','130.60.95.112','20200116114806' )]
[2020.01.16 11:48:06 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][ID: 13539 - affected rows: 1]
[2020.01.16 12:03:07 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][DELETE FROM Dirty WHERE id='13539' LIMIT 1]
[2020.01.16 12:03:07 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][Affected rows: 1]
[2020.01.16 12:03:07 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][INSERT INTO Dirty (`sip`, `tableName`, `recordId`, `expire`, `recordHashMd5`, `feUser`, `qfqUserSessionCookie`, `dirtyMode`, `remoteAddress`, `created`) VALUES ( '5e203efef41d2','phd_graduation','400','2020-01-16 12:18:06','c4472b22659d70b6861455db23ca999c','SHORT','s6kua7c734irt5f2mhsi7m1k7t','exclusive','130.60.95.112','20200116120307' )]
[2020.01.16 12:03:07 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][ID: 13546 - affected rows: 1]
[2020.01.16 15:53:01 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][DELETE FROM Dirty WHERE id='13546' LIMIT 1]
[2020.01.16 15:53:01 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][Affected rows: 1]
[2020.01.16 15:53:01 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][INSERT INTO Dirty (`sip`, `tableName`, `recordId`, `expire`, `recordHashMd5`, `feUser`, `qfqUserSessionCookie`, `dirtyMode`, `remoteAddress`, `created`) VALUES ( '5e203efef41d2','phd_graduation','400','2020-01-16 16:08:00','c4472b22659d70b6861455db23ca999c','SHORT','s6kua7c734irt5f2mhsi7m1k7t','exclusive','130.60.95.112','20200116155301' )]
[2020.01.16 15:53:01 +0100][130.60.95.112][FE:SHORT,form:phd_check-head][ID: 13574 - affected rows: 1]
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][DELETE FROM Dirty WHERE id='13574' LIMIT 1]
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][Affected rows: 1]
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][INSERT INTO FormSubmitLog (formData, sipData, clientIp, feUser, userAgent, formId, recordId, pageId, sessionId, created)VALUES ('{"email":"","username":"","password":"","recordHashMd5":"c4472b22659d70b6861455db23ca999c","nodb_check-student-400":"1","nodb_check-committee-400":"1","nodb_student-info-400":"STUDENT","colloquium_start-400":"2020-03-05 15:00","colloquium_duration-400":"01:00","colloquium_place-400":"WAD P106a","disputation_start-400":"2020-03-05 16:00","disputation_duration-400":"01:00","disputation_place-400":"WAD P106a","_sipForTypo3Vars":"5e203efef412a"}', '{"__dbIndexData":"1","check_head_done":"2020-01-16 11:46:22","form":"phd_check-head","r":"400","s":"5e203efef41d2","urlparam":"__dbIndexData=1&check_head_done=2020-01-16 11:46:22&form=phd_check-head&r=400"}', '130.60.95.112', 'SHORT', 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36', '1002', '400', '19', 's6kua7c734irt5f2mhsi7m1k7t', NOW())]
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][ID: 31466 - affected rows: 1]
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][UPDATE `phd_graduation` SET `check_head_done` = '2020-01-16 11:46:22', `colloquium_start` = '2020-03-05 15:00', `colloquium_duration` = '01:00', `colloquium_place` = 'WAD P106a', `disputation_start` = '2020-03-05 16:00', `disputation_duration` = '01:00', `disputation_place` = 'WAD P106a' WHERE id = '400']
[2020.01.16 15:55:46 +0100][130.60.95.112][FE:SHORT,Page:19,tt:48,form:phd_check-head][Affected rows: 1]
[2020.01.16 15:55:50 +0100][130.60.95.112][FE:SHORT,Page:84,tt:171,level:40.10][UPDATE typo3_studentadmin.fe_users SET usergroup='4,1' WHERE username='SHORT' AND deleted='0' LIMIT 1]
[2020.01.16 15:55:50 +0100][130.60.95.112][FE:SHORT,Page:84,tt:171,level:40.10][Affected rows: 1]

UPDATE typo3_studentadmin.fe_users feuert beim Login

Any Ideas wo das Problem herkommt und wie ich das vermeiden kann? (und betrifft das wirklich nur uns?)

Actions #1

Updated by Benjamin Baer about 4 years ago

  • Assignee set to Benjamin Baer
Actions #2

Updated by Benjamin Baer about 4 years ago

  • Status changed from New to Feedback
Actions #3

Updated by Benjamin Baer about 4 years ago

Gespeichert wird ueber eine API, diese benoetigt keine Typo3 Session.

Weitergeleitet wird nach der Antwort von der API - warum er dann auch auf eine Login Seite kam und entsprechend nichts von der Forward Seite ausgefuehrt wurde.

Das Frontend Login laeuft nach 24h ab, nach maxLifetime - was durchaus moeglich ist, falls sie ihren Computer nur in den Sleep Modus schalten und nicht herunterfahren.

Generell kann man das Problem ganz vermeiden, wenn du das Update und den Mail versand direkt im Formular ueber Actions ausfuehrst. Falls irgendwie moeglich waere also das zu empfehlen.

Actions #4

Updated by Nicola Chiapolini about 4 years ago

Vielen Dank für die Antwort.

Wie das Log zeigt, waren zwischen Login und speichern nur 4h. Das sollte eigentlich klar unter den lifetime settings sein...

Betreffend Action Elementen: Ich versuche die möglichst zu vermeiden. Die sind viel weniger flexibel und verständlich als ein normaler Report [1]. Entspechend ist das für uns keine Lösung. Eine möglicher Hack wäre aber wohl eine Datenfeld mit Timestamp und eine BeforeSave-Action, die den Save blockiert, falls zu viel Zeit verstrichen ist.
Statt ein solches Konstrukt in jedes Formular einzubauen, fände ich es aber natürlich sinnvoller, wenn beim Formular konfiguriert werden könnte, dass die API eine FE-Session verlangen soll.
Allzu dringend ist das Problem aber noch nicht, so häufig scheint das nicht aufzutreten.

[1] Dinge die ich als Nachteile der Action sehe:
- Action mit mehreren, von einander abhängenden Queries über verschiedene Tabellen sind unmöglich/unverständlich.
- keine Versionierung
- ich kann ein Action-Element nicht in einem anderen Formular wiederverwenden

Das betrofene Report-Element sieht so aus

10.sql = SELECT firstname AS _firstname, name AS _name, mail_uzh AS _mail, shortname AS _shortname, colloquium_start AS _colst, disputation_start AS _dispst, colloquium_duration AS _coldur, disputation_duration AS _dispdur, colloquium_place AS _colpl, disputation_place AS _disppl 
FROM phd_graduation 
WHERE id='{{r:SE}}' AND check_head_done IS NOT NULL AND reg_mails=1

10.2.sql = SELECT 't:{{mail:R::s}}|f:{{phd_from_email:UE}}|s:Registration for Graduation Confirmed|b:
Dear {{firstname:R::s}} {{name:R::s}}\n
\n
The head of your PhD committee confirmed your registration.\n
\n
Your defense is scheduled as follows:\n
\ \ colloquium start:\ \ \ \ \ {{colst:R::s}}\n
\ \ colloquium duration:\ \ {{coldur:R::s}}\n
\ \ colloquium place:\ \ \ \ \ {{colpl:R::s}}\n
\ \ disputation start:\ \ \ \ {{dispst:R::s}}\n
\ \ disputation duration:\ {{dispdur:R::s}}\n
\ \ disputation place:\ \ \ \ {{disppl:R::s}}\n
\n
As a next step you now need to visit the Office of Student Affairs no later than 4 weeks before the defense and bring the following documents:\n
\ \ - two copies of your dissertation’s title page\n
\ \ - a copy of your passport/id-card\n
\n
best wishes\n
Office of Student Affairs
' AS _sendmail

10.3.sql = UPDATE phd_graduation SET reg_mails=2  WHERE id='{{r:SE}}'

10.10.sql = UPDATE `phd_milestones` SET 
confirmed=NOW(), confirmed_by='{{feUser:TE}}'
WHERE type=7 AND student='{{shortname:RE}}'

Actions #5

Updated by Carsten Rose about 4 years ago

Hallo Nicola

Session Timeout
---------------
  • FE Login: Wir haben eine T3 Instanz bei der wir schnell ausgeloggt werden (30mins). Andere T3 Instanzen auf dem gleichen Server haben 24h. Erklaerung: Keine.
Formular speichern, Mails versenden, Records aktualisieren
----------------------------------------------------------
  • Ein Unterbruch in dieser Kette kennen wir nicht, da wir alles in einem Form machen (und kein Report nutzen).
  • Mittlerweile geht das sogar in einem einzigen FormElement.type=sendmail (alles an einem Ort: Parameter.sqlBefore|sqlAfter).
  • Formulare mit Versionierung: #9602

CU
Carsten

Actions #6

Updated by Nicola Chiapolini about 4 years ago

Carsten Rose wrote:

  • FE Login: Wir haben eine T3 Instanz bei der wir schnell ausgeloggt werden (30mins). Andere T3 Instanzen auf dem gleichen Server haben 24h. Erklaerung: Keine.

Ok. Dann investiere ich da für den Moment auch nicht mehr Zeit...

Formular speichern, Mails versenden, Records aktualisieren
----------------------------------------------------------
  • Ein Unterbruch in dieser Kette kennen wir nicht, da wir alles in einem Form machen (und kein Report nutzen).

Ok.

  • Mittlerweile geht das sogar in einem einzigen FormElement.type=sendmail (alles an einem Ort: Parameter.sqlBefore|sqlAfter).

Das tönt spannend. Kannst du mir ein Beispiel senden (oder gleich mein Beispiel in Parameter.sql* umbauen)?

Actions #7

Updated by Carsten Rose about 4 years ago

Allgemeine Absender hinterlegen wir zentral in der QFQ Config, in Deinem Fall koennte das sein: '{{phd_from_email:Y}}'.

FormElement:

Ttitle: sendmail: registration confirmation
Typ: sendmail
Value:
------------------------------------------------------------------
Dear {{firstname:V::s}} {{name:V::s}}

The head of your PhD committee confirmed your registration.

Your defense is scheduled as follows:
  colloquium start:     {{colloquium_start:V::s}}
  colloquium duration:  {{colloquium_duration:V::s}}
  colloquium place:     {{colloquium_place:V::s}}
  disputation start:    {{disputation_start:V::s}}
  disputation duration: {{disputation_duration:V::s}}
  disputation place:    {{disputation_place:V::s}}

As a next step you now need to visit the Office of Student Affairs no later than 4 weeks before the defense and bring the following documents:
  - two copies of your dissertation’s title page
  - a copy of your passport/id-card

best wishes
Office of Student Affairs
------------------------------------------------------------------

Parameter:
------------------------------------------------------------------
fillStoreVar={{! SELECT firstname, name, mail_uzh, shortname, colloquium_start, disputation_start, colloquium_duration, disputation_duration, colloquium_place, disputation_place
FROM phd_graduation 
WHERE id='{{id:R0}}' AND check_head_done IS NOT NULL AND reg_mails=1 }}

sendMailTo={{mail_uzh:V::s}}
sendMailSubject=Registration for Graduation Confirmed
sendMailFrom = {{phd_from_email:Y}}

sqlBefore = {{UPDATE phd_graduation SET reg_mails=2  WHERE id='{{id:R0}}'}}
sqlAfter = {{UPDATE `phd_milestones` SET confirmed=NOW(), confirmed_by='{{feUser:TE}}' WHERE type=7 AND student='{{shortname:VE}}'}}
------------------------------------------------------------------

Actions #8

Updated by Nicola Chiapolini about 4 years ago

Hoi Carsten

Vielen Dank für deine ausführliche Antwort. Habe das eben endlich ausprobiert und das funktionert im Allgemeinen sehr gut. Ein paar Anmerkungen/Fragen:

  • Wir benutzen qfq config nicht for Konfiurations-Variablen stattdessen sind die bei uns in einer DB-Tabelle und werden beim Login geladen mit:
    
    1.sql = SELECT label FROM _constants
    1.content = hide
    1.1.sql = SELECT value AS '_={{label:R}}' FROM _constants WHERE label='{{label:R}}'
    
  • Auch das ursprüngliche Formular des Studenten funktioniert analog, das muss aber auch vor dem finalen Submit zwischengespeichert werden können. Dann darf das Mail natürlich nicht ausgelöst werden. Könnte ich das mit einem sendMail-Element auch lösen?
  • Für mich ist nicht offensichtlich wann welches der Queries in Parameter ausgeführt wird. (sqlBefore wird offensichtlich nach fillStoreVar und fillStoreVar wird erst während dem Speichern und nicht während dem Laden ausgeführt) Das macht diese Methode deutlich weniger verständlich als die Report-Syntax. (Und im Gegensatz zur Report Syntax, sind die Queries jetzt auch nicht von einander abhänig. Das sqlBefor-Query wird also wohl auch ausgeführt, wenn etwas beim Mail-Versand schief geht. Auch das ist ein kleiner nachteil)
  • Schliesslich nicht direkt mit dem verknüft: Kann ich die Font-Family der Text-Area irgendwo einfach auf monospace auf ändern?
Actions #9

Updated by Carsten Rose about 4 years ago

  • Tracker changed from Support to Bug
Actions

Also available in: Atom PDF