Contao 3.5.3x, modules.php, Backend-Umleitungsfehler 303

Wir haben bei unserer Konfiguration (s.u.) das Problem, dass nach einiger Zeit fehlerfreien Laufens das Backend nicht mehr erreichbar ist: Umleitungsfehler 303.

Es wurde im BE kein Cache geleert. Wir fanden heraus, dass die /system/cache/config/modules.php im Abschnitt static::$active = array das repository drin hat, obwohl es im Abschnitt static::$disabled = array stehen müsste. Da stand es wohl auch mal, sonst würde das BE ja nicht arbeiten.
Es gibt keine .skip-Datei im /repository-Ordner, die haben wir jetzt reingelegt. (nach Tests in anderen Installationen istz die aber nicht notwendig, oder?)

In der localconfig steht aber auch $GLOBALS['TL_CONFIG']['inactiveModules'] = 'a:1:{i:0;s:10:"repository";}';

Meine Fragen:
1. Welcher Prozess erstellt/ändert die modules.php, .skip?
2. Wodurch wird das ausgelöst?
3. Warum wird die modules.php im laufenden Betrieb geändert, obwohl sich die Konfiguration/Cache nicht ändert?

Fehlen da Rechte?

Während der Entwicklung in einer anderen Konfiguration (nicht Docker, .skip Datei war auch nicht da) lief es problemlos.
In anderen Installationen ist die modules.php teilweise sehr alt (da läuft es auch problemlos).

Unsere Konfiguration:
Contao 3.5.33/35 im Docker-Container
Composer
Metamodels

Diese Ordner sind 'gemountet' - liegen außerhalb auf dem Server (für Backups):
/.htaccess
/files
/templates
/composer/composer.json
/composer/.htaccess
/system/config/dcaconfig.php
/system/config/localconfig.php
/system/config/pathconfig.php
/system/config/initconfig.php
/system/config/langconfig.php

Bis auf files und templates sind die Dateien auch im Container nicht schreibbar.

Danke für Eure Hilfe.

Bei Umleitungsfehlern würde ich grundsätzlich erstmal im Browser den Cache und die Cookies löschen. Mit dem "nach einiger Zeit fehlerfreien Laufens" kann ich aber nichts anfangen. Ich könnte zwar auch so schreiben, doch dem war IMMER ein Update von Contao vorausgegangen bisher.

Hallo Samson1964, danke.
Naja, wie gesagt, es läuft erst stabil, und dann plötzlich ist (durch die Änderung der modules.php) der Backend-Fehler.
Am Browser-Cache und Cookies liegt es nicht, denn auch über die Shell mit curl kommt der Fehler.

An der Installation wird wie gesagt nix gemacht (install und cache [übers Backend]), macht der Contao-cron das etwas?

Es muss mit Docker zusammenhängen, aber wie genau, deswegen die Frage nach den (automatischen) Prozessen.

Weitere Anmerkungen/Lösungen?

Danke.

Der interne Cache wird bei der Installation von Erweiterungen gelöscht und dann nur durch manuelles Betätigen des entsprechenden Buttons im Backend wieder aufgebaut


Die .skip Datei wird generiert, wenn du in den System Einstellungen eine Erweiterung deaktivierst.

Hallo spooky, ok verstehe ich. Soweit ist mir das aus meiner Erfahrung auch bekannt.
Das 'Problem' ist aber,
* es wird nix installiert in der Zwischenzeit (never change ...)
* es wird nix deaktivert (es steht ja nur des repository im array)
* das repository wurde 'eigentlich' gleich bei der Installation durch Composer ersetzt
(wie erwähnt lag aber keine .skip-Datei dort)

Aus deinen Hinweisen lese ich also, dass kein 'automatisches (cron) Script' dazwischenfunkt?
hmmm...

Was kann es noch sein? Dateirechte?
Danke

Naja, du musst primär mal herausfinden woher der "Umleitungsfehler 303" kommt. Warum ist es überhaupt ein Umleitungsfehler? Was genau passiert?

Zitat:

---

Zitat von Spooky

Naja, du musst primär mal herausfinden woher der "Umleitungsfehler 303" kommt. Warum ist es überhaupt ein Umleitungsfehler? Was genau passiert?

---

Gute Frage.
beim curl geschieht das:

Code:

---

$ curl -I https://domaincom/contao/
HTTP/1.1 303 See Other

---

Also dadurch, dass das Modul 'repository' in dem active-Array steht, kommt er nicht weiter, da ja in der DB diese Daten nicht stehen (bei composer-Installation wohl entfernt so verstehe ich das.).
Damit läuft die Suche nach 'repository'-Sachen ins Leere...
Das Folgende ist nur das Ergebnis, die Frage ist, WARUM wird die Datei (modules.php) geändert (durch contao?) und das 'repository' ins active-Array geschoben...

Das kann man nachvollziehen, indem man das repository ins active-Array schiebt.

Aus Firebug -> Netzwerkanalyse - Im Header steht:

Code:

---

Anfrage:
Host: domain.de/contao/
User-Agent: Mozilla/
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-DE,en;q=0.8,de;q=0.6,en-US;q=0.4,pl;q=0.2
Accept-Encoding: gzip, deflate
Cookie: BE_PAGE_OFFSET=0; PHPSESSID=xxx;
Connection: keep-alive
Upgrade-Insecure-Requests: 1

Antwortkopfzeilen:
HTTP/1.1 303 See Other
Date: Wed, 30 May 2018 09:53:17 GMT
Server: Apache/
X-Powered-By: PHP/7.1.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Location: domain.de/contao/
Keep-Alive: timeout=3, max=79
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

---

Danke.

Zitat:

---

Zitat von gracilis

Gute Frage.
beim curl geschieht das:

Code:

---

$ curl -I https://domaincom/contao/
HTTP/1.1 303 See Other

---

---

Im eingeloggten Zustand wäre das normal, denn da wirst du ausgeloggt und nochmal auf auf https://domain.com/contao/ weitergeleitet. Über cURL ist das schon mal verdächtig, da du da ja vermutlich nicht eingelogged bist.

Zitat:

---

Zitat von gracilis

Also dadurch, dass das Modul 'repository' in dem active-Array steht, kommt er nicht weiter, da ja in der DB diese Daten nicht stehen (bei composer-Installation wohl entfernt so verstehe ich das.).
Damit läuft die Suche nach 'repository'-Sachen ins Leere...
Das Folgende ist nur das Ergebnis, die Frage ist, WARUM wird die Datei (modules.php) geändert (durch contao?) und das 'repository' ins active-Array geschoben...

---

In wie fern hat das was mit deinem Problem zu tun? Du schreibst "kommt er nicht weiter". Was genau passiert?

Zitat:

---

Zitat von Spooky

In wie fern hat das was mit deinem Problem zu tun? Du schreibst "kommt er nicht weiter". Was genau passiert?

---

Na , DAS ist das Problem, wenn eben das (nicht genutzte/nicht aktive) repository plötzlich im active-Array steht, kommt der 303 Fehler. Und dieses 'im active-Array stehen' geschieht eben unerwartet...

Ändere das mal bei Dir in einem (lokalen) Testweb, dann siehst Du es.

Der 303 Redirect ist ja kein Fehler. Meinst du es kommt zu einem unendlichen 303 Redirect?

Zitat:

---

Zitat von Spooky

Der 303 Redirect ist ja kein Fehler. Meinst du es kommt zu einem unendlichen 303 Redirect?

---

Sorry, ja unendlicher redirect (FF macht ja nur 20 Schritte)
Hast Du es mal getestet?

Zitat:

---

Zitat von gracilis

Es gibt keine .skip-Datei im /repository-Ordner, die haben wir jetzt reingelegt. (nach Tests in anderen Installationen istz die aber nicht notwendig, oder?)

---

Doch, die ist notwendig. Danach muss auch der interne Cache aufgebaut werden.



Der unendliche Reload wird durch ContaoCommunityAlliance\Contao\Composer\Client::disableOldClientHook() ausgelöst. Dort wird nämlich die .skip Datei für das Repostiory geschrieben und dann die Seite neu geladen. Da aber bereits der Cache aktiv und im Cache festgehalten ist, dass das Repository aktiv ist, hat dies keine Auswirkung und die Seite wird daher immer wieder neu geladen.


Zu dieser Situation sollte es theoretisch nie kommen. Irgendwas in deinem Setup führt zu der Änderung im Internen Cache. Ohne die gesamte Installation zu kennen kann ich hier auch nicht weiterhelfen.

Zitat:

---

Zitat von gracilis

Diese Ordner sind 'gemountet' - liegen außerhalb auf dem Server (für Backups):
/.htaccess
/files
/templates
/composer/composer.json
/composer/.htaccess
/system/config/dcaconfig.php
/system/config/localconfig.php
/system/config/pathconfig.php
/system/config/initconfig.php
/system/config/langconfig.php

Bis auf files und templates sind die Dateien auch im Container nicht schreibbar.

---

Befindet sich die /system/modules/repository/.skip Datei bereits im Container?

Zitat:

---

Zitat von Spooky

Befindet sich die /system/modules/repository/.skip Datei bereits im Container?

---

Hallo spooky, ja, aber erst später (manuell). Warum sie nicht drin lag, muss ch noch mal in Erfahrung bringen.
Was genau brauchst für 'gesamte Installation'?
Aber ich wiedehole mich gern, warum wird im laufenden Betrieb, also nachdem das Backend wochenlang liefe und keine Änderung am system erfolgt, plötzlich diese modules.php umgeschrieben.

Ich frage beim Kunden nochmal nach dem Stand vor/nach dem ersten 303. Er haz sich ja eine 'Dockerfile' gebaut, mit der er das Image neu erstellt (das ist nur ein Download/Hinlegen von Contao) und fügt die Docker-Verknüpfung hinzu (zu den außen liegenden files). Im Download sind ja kein .skip-Dateien. In diese Docker-Geschichte habe ich nicht so den Einblick... Ich versuchs mal mit fragen.

Danke.

Zitat:

---

Zitat von gracilis

Hallo spooky, ja, aber erst später (manuell).

---

Naja aber das bedeutet ja wenn der Docker Container neu gestartet wird, ist die Datei wieder weg.

Befindet sich auch der gesamte, aufgebaute, interne Cache im Docker Container?

Zitat:

---

Zitat von Spooky

Naja aber das bedeutet ja wenn der Docker Container neu gestartet wird, ist die Datei wieder weg.

Befindet sich auch der gesamte, aufgebaute, interne Cache im Docker Container?

---

Ja, durch das cron und ein eigenes script wird der cache wieder im Docker Container erstellt.

Ja, dann ist das das Problem. Unter diesen Umständen verursacht die Paketverwaltungs-Erweiterung (composer-client) diesen Fehler.

Ihr müsst euren Docker Container neu bauen, damit sich die .skip Dateien bereits im Container befinden, und nicht erst zur Laufzeit.

Wobei, 100%ig kann ich das immer noch nicht nachvollziehen.

Befindet sich auch die localconfig.php im Docker Container? Wenn ja, befindet sich bereits $GLOBALS['TL_CONFIG']['inactiveModules'] = 'a:1:{i:0;s:10:"repository";}'; in der localconfig.php im Docker Container?

Zitat:

---

Zitat von Spooky

Wobei, 100%ig kann ich das immer noch nicht nachvollziehen.

Befindet sich auch die localconfig.php im Docker Container? Wenn ja, befindet sich bereits $GLOBALS['TL_CONFIG']['inactiveModules'] = 'a:1:{i:0;s:10:"repository";}'; in der localconfig.php im Docker Container?

---

Nein, wie oben erwähnt ist die localconfig außerhalb des Containers, (sie wird ja mit gesichert), und enthält aber den $GLOBALS-Eintrag (siehe oben) (Wann genau sie den erhielt, müsste ich auch erst erfragen :-) ). Aber das repository wurde bei INSTALLATION schon entfernt/ersetzt.
Danke.