Session-Timeout-Dauer für TYPO3 Backend-Modul anpassen

wini2

@Eric Harrer
Ich glaube auch, wir reden von der selben Sache. Die Terminologie ist hier etwas missverständlich. Leider ist mir keine unterschiedl. Bez. für die site-config.yaml und die sitepackage-config.yaml bekannt. Gilt auch für die settings.yaml. Auch scheint das Synonym-Wörterbuch bei dem Backend-Module nichts hergegeben zu haben. Modul Site Management > Settings -> Site Settings bzw. Modul Site Management > Einstellungen -> Site-Einstellungen. Dummerweise heißt auch bei Verwaltungswerkzeugen ein Modul Settings bzw. Einstellungen.

Apropos - hat zwar absolut nix damit zu tun - aber wo das schon ein profunder TYPO3 Entwickler liest: Kann man eigentlich die Zeit einstellen, die es braucht, bis man sich beim letztgenannten Modul wieder anmelden muss, ähnlich wie bei ['TYPO3_CONF_VARS']['BE']['sessionTimeout'] (ist ein wenig kurz, wie ich finde)?

Eric Harrer

wini2 Ich habe deine Anschlussfrage in einen separaten Thread ausgelagert.
Bitte künftig gleich einen neuen Thread eröffnen 😉

Zu deiner Frage:

Die Dokumentation unterscheidet zwei Szenarien:

Standalone-Aufruf über /typo3/install.php
Hier ist die Datei ENABLE_INSTALL_TOOL erforderlich, um das Install Tool (bzw. die „Verwaltungswerkzeuge“) zu öffnen.
- Die Datei wird nach dem Logout oder spätestens nach 60 Minuten automatisch gelöscht.
- Mit dem Inhalt KEEP_FILE lässt sich die automatische Löschung verhindern. Das empfiehlt sich allerdings nur in lokalen Entwicklungsumgebungen, da es sonst ein Sicherheitsrisiko darstellt.
Zugriff über das Backend als System Maintainer
In diesem Fall gilt die normale Backend-Sessionlaufzeit. Sie ist also nicht auf 60 Minuten beschränkt.

Eigene Beobachtung / offene Frage:
In meinen Tests mit TYPO3 v12 und v13 wurde ich nach dem Backend-Login als System Maintainer nicht mehr zusätzlich nach dem Install-Tool- oder Benutzerpasswort gefragt – selbst bei frischen Installationen.

Früher erinnere ich mich, dass man hier nach dem BE-Login nochmals sein Benutzerpasswort (oder alternativ das Install-Tool-Passwort) bestätigen musste.

Weiß jemand, ob sich dieses Verhalten geändert hat? Falls ja, wäre das ja praktisch, da dann der einmalige Backend-Login für Maintainer ausreicht.

wini2

Eric Harrer
Du hast natürlich recht, bitte um Entschuldigung, Wenn ich geahnt hätte, dass das so ein großes Fass ist, das ich damit aufmache, hätte ich es gelassen oder es in eine eigene Frage gepackt. Ich hatte gehofft, ein ['TYPO3_CONF_VARS']['BE']['wasAuchImmer'] würde reichen.

ENABLE_INSTALL_TOOL mit KEEP_FILE tut's bei mir im Hosting-Paket nicht, egal ob in public, transient oder config-Ordner, auch nicht im Debug-Preset als Maintainer.

Bei DDEV scheint die Sache mit .ddev/config.yaml des Rätsels Lösung; bequemerweise habe ich mich gar nicht gefragt, warum kein Passwort nötig ist.

Andreas Hirsch

Also ich muss in "Production" pro BE-Session 1x das Benutzerpasswort eingeben. In der lokalen DDEV-Installation ist kein Passwort nötig. Getestet in v12 und v13.

Eric Harrer

Andreas Hirsch Danke dir, das war es!

Der Installtool-Login aus dem Backend heraus ist abhängig vom konfigurierten TYPO3-Kontext (→ Umgebungsvariable TYPO3_CONTEXT).

Ich konnte beide Fälle nun in DDEV lokal nachstellen.

Mit folgendem Eintrag in der Datei .ddev/config.yaml ist kein zusätzlicher Login im Backend erforderlich:

web_environment:
    - TYPO3_CONTEXT=Development

und mit folgendem Eintrag (oder wenn gar nichts für web_environment konfiguriert wurde) in der Datei .ddev/config.yaml ist ein zusätzlicher Login im Backend erforderlich:

web_environment:
    - TYPO3_CONTEXT=Production

Andreas Hirsch

Das deckt sich aber nicht ganz mit der Doku.

The System Maintainer role allows for selected backend users to access the Admin Tools components from within the backend without further security measures.

Im Development-Kontext haben alle admin-User Zugriff, ansonsten nur die System Maintainer. Ich bin aber auch in Production System Maintainer und muss totzdem für den Zugriff einmal das Passwort eingeben. 🤔

Eric Harrer

Andreas Hirsch
Hier habe ich etwas zu diesem Verhalten in der "Application Context"-Dokumentation gefunden im Abschnitt "Development":

auf deutsch steht dort folgendes:

Die Menüelemente des Installtools im Backend erfordern keine zusätzliche Passworteingabe mehr.

Administratoren ohne "System Maintainer"-Berechtigung können ebenfalls die Menüpunkte für das Installtool sehen.

Der letzte Punkt war mir neu. Danke dir für den Hinweis.

Tatsächlich wäre es hilfreich, wenn diese Dinge auch in der "Install tool"-Dokumentation im Kapitel "Accessing the Install Tool in the backend" stehen würden. Da erstelle ich bei Gelegenheit mal einen PR.

Andreas Hirsch

Eric Harrer Aber wie gesagt: Auch als System Maintainer muss ich "in Production" ein Passwort eingeben. Passwortlos ist es scheinbar nur im Development-Kontext.

Eric Harrer

Andreas Hirsch Ja, das stimmt – dieser Punkt geht aus der Dokumentation nicht eindeutig hervor.

Ich vermute, dass mit „further security measures“ lediglich die zusätzliche Authentifizierung über das Dateisystem mittels ENABLE_INSTALL_TOOL gemeint war – nicht jedoch die Passwortabfrage im Install Tool selbst.

In der „Application Context“-Dokumentation ist das im Abschnitt Production deutlicher formuliert. Dort heißt es auf Deutsch:

„Zum Aufrufen der Menüelemente des Install Tools ist die zusätzliche Eingabe eines Passworts erforderlich („sudo-Modus“).“

Fazit: In der „Install Tool“-Dokumentation sollten die kontextabhängigen Auswirkungen (Production vs. Development) klarer herausgestellt werden.

Jetzt brauchen wir nur noch den PR im Doku-Repository, damit sich die Nachwelt nicht mehr den Kopf darüber zerbrechen muss 😉

Eric Harrer

Hier der PR:
https://github.com/TYPO3-Documentation/TYPO3CMS-Reference-CoreApi/pull/6054

In diesem Zusammenhang habe ich noch herausgefunden, dass sich der Kontext Testing etwas anders verhält:

Im Gegensatz zum Development-Kontext, wo Admins (mit oder ohne System-Maintainer-Rolle) direkt ohne weitere Sicherheitsabfrage Zugriff auf das Install Tool haben, wird im Testing-Kontext zwar ebenfalls das Menü angezeigt, der Zugriff erfordert aber eine zusätzliche Authentifizierung (Backend-Passwort oder Install-Tool-Passwort).

Damit verhält sich Testing in dieser Hinsicht näher an Production.

Andreas Hirsch

Eric Harrer So hab ich das aber auch verstanden: Ohne PW nur im Development-Kontext und das für alle Admins, in ~~allen anderen Kontexten~~ nur die System Maintainer und mit PW.
Edit: Doch falsch verstanden. 😑 In Testing Anzeige wie in Development, aber mit Passwort.
Und noch eine Ungenauigkeit bzw. Fehler in der Doku zum Application Context:

Development: In the backend, the corresponding table field is also displayed in square brackets after each label when editing data records.

Die Feldbezeichnungen werden nur angezeigt, wenn Debug an ist, unabhängig vom Application Context.

Eric Harrer

Andreas Hirsch Ok, kannst du demnach bestätigen, dass der PR inhaltlich korrekt ist? Es ist gut wenn das ein weiteres Paar Augen bestätigen kann.

Hier nochmal auf deutsch ausformuliert:

Development Kontext:
Alle Backend-Benutzer mit Administratorrechten können ohne weitere Sicherheitsmaßnahmen direkt auf die Admin Tools zugreifen.

Testing Kontext:
Alle Backend-Benutzer mit Administratorrechten können die Admin Tools im Backend sehen. Allerdings ist ein zusätzlicher Authentifizierungsschritt („sudo-Modus“) erforderlich. Der Benutzer muss entweder sein eigenes Backend-Passwort oder das Install Tool-Passwort erneut eingeben.

Production Kontext:
Nur Benutzer, die als System Maintainer aufgeführt sind, können auf die Admin-Tools zugreifen. Darüber hinaus ist ein zusätzlicher Authentifizierungsschritt („sudo-Modus“) erforderlich. Der Benutzer muss entweder sein eigenes Backend-Passwort oder das Passwort für das Installations-Tool erneut eingeben, bevor ihm Zugriff gewährt wird.

Zu deiner Entdeckung:

"Development: In the backend, the corresponding table field is also displayed in square brackets after each label when editing data records."
Die Feldbezeichnungen werden nur angezeigt, wenn Debug an ist, unabhängig vom Application Context.

Guter Fund 👍 Das kann ich bestätigen.

Unabhängig davon, in welchem TYPO3-Kontext (Umgebungsvariable TYPO3_CONTEXT) man sich befindet, werden Feldbezeichner im Backend nur dann angezeigt, wenn $GLOBALS['TYPO3_CONF_VARS']['BE']['debug'] auf true gesetzt ist.

Jetzt bist du dran, erstell doch direkt mal einen PR dazu 😉

Eric Harrer

wini2

ENABLE_INSTALL_TOOL mit KEEP_FILE tut's bei mir im Hosting-Paket nicht, egal ob in public, transient oder config-Ordner, auch nicht im Debug-Preset als Maintainer.

Das ist merkwürdig. Also meinen Tests nach bleibt die Datei var/transient/ENABLE_INSTALL_TOOL mit exakt dem Text-Inhalt KEEP_FILE auch nach einem Logout aus dem Installtool und/oder dem Backend erhalten. Ich sehe sogar eine Meldung dazu in der Installtool-Loginmaske dazu.

(Beispiel aus v13)

Was konkret meinst du denn mit "tut's bei mir nicht"? Möglicherweise hast du andere Erwartungen. KEEP_FILE sorgt erstmal nur dafür, dass die Datei ENABLE_INSTALL_TOOL nicht automatisch gelöscht wird. Ein zusätzlicher Login ist je nach Kontext im Backend oder bei einem Direktaufruf des Installtools ist trotzdem notwendig.

Andreas Hirsch

Eric Harrer Gut, wenn man's nochmal ausprobiert:
Ich hab meine DDEV-Installation auf "Testing" umgestellt. Auch da sehen nur die System Maintainer die Verwaltungswerkzeuge. Also ist das Install-Tool für die Nicht-System-Maintainer nur im Development-Kontext zu sehen und da ohne weitere Authentifizierung. In den restlichen Kontexten (Testing und Production) nur für System Maintainer und mit zusätzlicher Authentisizierung (Benutzerpasswort oder Install-Tool-Passwort.

Zum Thema "Feldbezeichner" würd ich lieber ein Feature-Request aufmachen, das hätte ich gerne unabhängig vom Debug-Modus.

wini2

Eric Harrer
Du hast recht, die Datei ENABLE_INSTALL_TOOL mit KEEP_FILE wird nicht gelöscht. und auch im Install-Tool (über TYPO3/install.php) wird das angezeigt.

Meine Ausgangsfrage - mal eben den timeout-Wert hochsetzten, beantwortet das nicht. Offenbar muss man das Login ganz ausschalten (geht nur über htaccess und ApplicationContext), was mir zu umständlich und zeitaufwändig ist. Das Passwort im BE zu bestätigen, ist da die lästigere, aber einfachere Lösung.

Eric Harrer

FYI: Der Install Tool Doku PR wurde nun gemergt:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Security/GuidelinesIntegrators/InstallTool.html#security-install-tool-backend-access
Danke für die Mithilfe!

Eric Harrer

Andreas Hirsch

Ich hab meine DDEV-Installation auf "Testing" umgestellt. Auch da sehen nur die System Maintainer die Verwaltungswerkzeuge.

Das kann ich so nicht bestätigen. Hier der Beweis in einem Screenshot:

Wie man erkennen kann

befinde ich mit im "Testing"-Kontext und
es existiert kein Eintrag für $GLOBALS['TYPO3_CONF_VARS']['SYS']['systemMaintainers'] und
die Install-Tool Module sind sichtbar

Zum Thema "Feldbezeichner" würd ich lieber ein Feature-Request aufmachen, das hätte ich gerne unabhängig vom Debug-Modus.

Das kannst du selbstverständlich ergänzend tun. Features werden – sofern die Core-Merger deine Auffassung teilen und es umsetzen – definitionsgemäß nur in der jeweils neuesten Version (derzeit v14) berücksichtigt. Für v13 gilt bereits Feature-Freeze. Unabhängig davon wäre eine Anpassung der Dokumentation, die den Ist-Zustand für v12/v13 beschreibt, also in jedem Fall sinnvoll.

Andreas Hirsch

Hm...

Testing-Kontext
Nur der Admin (id 1) ist System Maintainer
Ich bin als anderer Admin eingeloggt
Keine Verwaltungswerkzeuge

Ich hab auch mal die System Maintainer komplett gelöscht und mich als admin eingeloggt, keine Änderung. Ich hab im Testing-Kontext die Verwaltungswerkzeuge nur für System Maintainer.

Eric Harrer

Andreas Hirsch
Danke dir für den Hinweis. Dann müssen wir nochmal einen Bugfix-PR einreichen 🙈

Das Verhalten hängt offenbar nicht nur vom aktuellen Application Context ab, sondern auch davon, ob der Array-Key systemMaintainers existiert, ob dass darin definierte Array leer ist oder ob eine darin definierte ID mit der ID des eingeloggten Backend-Benutzers übereinstimmt.

Es ergeben sich einige verschiedene denkbare Situationen, die ich systematisch der Reihe nach in v12/v13 durchgehen und testen möchte, bevor ich den nächsten PR einreiche. Es soll dann schließlich der letzte für dieses Thema sein 😅.

Folgende Dimensionen würde ich ausmultiplizieren/testen:

Kontext
- Development
- Testing
- Production
systemMaintainers
- Key existiert nicht
- Key existiert + leeres Array
- Key existiert + uid des eingeloggten Benutzers ist nicht enthalten
- Key existiert + uid des eingeloggten Benutzers ist enthalten
Sudo Modus notwendig

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS