PHP Fatal error: Uncaught cInvalidArgumentException

[Bernhard_4711]

Moin,
ich habe mal wieder eine mir nicht erklärbare Fehlermeldung bekommen:

Code: Alles auswählen

[17-Jan-2025 06:04:37 UTC] PHP Fatal error:  Uncaught cInvalidArgumentException: Object ID must be greater than 0. in /var/www/btmr/contenido/classes/class.registry.php:662
Stack trace:
#0 /var/www/btmr/contenido/classes/class.registry.php(199): cRegistry::_fetchItemObject()
#1 /var/www/btmr/contenido/classes/class.i18n.php(127): cRegistry::getLanguage()
#2 /var/www/btmr/contenido/classes/class.i18n.php(90): cI18n::translate()
#3 /var/www/btmr/contenido/includes/functions.i18n.php(57): cI18n::__()
#4 /var/www/btmr/contenido/plugins/form_assistant/classes/class.pifa.php(92): i18n()
#5 /var/www/btmr/contenido/plugins/form_assistant/includes/config.plugin.php(42): Pifa::i18n()
#6 /var/www/btmr/contenido/includes/functions.includePluginConf.php(56): include_once('...')
#7 /var/www/btmr/contenido/includes/frontend/include.front_content.php(92): require_once('...')
#8 /var/www/btmr/cms/front_content.php(43): include('...')
#9 {main}
  thrown in /var/www/btmr/contenido/classes/class.registry.php on line 662

[bodil]

Hi Bernhard,
ein bisschen Kontext wäre gut. Wann tritt der Fehler auf? Frontend? Backend? Spezielles Plugin?
Grüße!
bodil

[xmurrix]

Hallo zusammen,

der Fehler taucht auf, weil in der Plugin-Konfiguration vom "Form Assistant" Plugin die Funktion Pifa::i18n() aufgerufen wird.

Ich denke das passiert, wenn ein Besucher das Frontend initial aufruft, in der die Session erst erstellt wird und keine Sprache/kein Mandant zuvor in der Session gesetzt wurde.

Kurz zum Problem:
Plugin-Konfigurationen werden ziemlich am Anfang der Skripte geladen, bevor in CONTENIDO die Sprache oder der Mandant ermittelt wurde.
Daher sollte man nicht in der Plugin-Konfiguration Funktionen nutzen, die die Id der Sprache/des Mandanten benötigen. Der Aufruf von Pifa::i18n() versucht über cRegistry::getLanguage() die Sprache zu ermitteln. Da die Sprache (globale Variable $lang oder $load_lang) noch nicht gesetzt wurde, führt das zu einem Fehler.

Wenn wir das in Plugin-Konfigurationen doch erlauben wollen, müssten wir den Zeitpunkt zum Laden der Plugin-Konfigurationen zu einem späteren Zeitpunkt machen. Das führt aber dazu, dass sich die bisherige Logik ändert. Das kann andere unerwartete Effekte nach sich ziehen.

Ich erstelle mal ein Ticket in GitHub. Der Fehler stellt keine potenzielle Gefahr dar, ist aber ärgerlich.

Nachtrag:
Das GitHub Ticket dazu ist 521.

[Bernhard_4711]

ein bisschen Kontext wäre gut. Wann tritt der Fehler auf? Frontend? Backend? Spezielles Plugin?

Diese Fragen kann ich nicht beantworten; ich habe lediglich die Datei "errorlog.txt" mit diesem Inhalt gesehen.

[Bernhard_4711]

Ich erstelle mal ein Ticket in GitHub. Der Fehler stellt keine potenzielle Gefahr dar, ist aber ärgerlich.

Nachtrag:
Das GitHub Ticket dazu ist 521.

Vielen Dank!

[Designer]

Hallo zusammen,

ich habe eine Idee, um den Fehler mit der Pifa::i18n() Funktion zu vermeiden. Könnte man nicht die Initialisierung der Sprach- und Mandant-IDs nach vorne ziehen, bevor das Plugin geladen wird? Das könnte solche Fehler verhindern, da die benötigten IDs schon bereit wären. Vielleicht bin ich auch komplett falsch.

[xmurrix]

Im Frontend ist die Initialisierung grob folgendermaßen:

1. Laden der Konfiguration-Dateien des Mandanten
2. Laden der Dateien für Konstanten und Umgebung
3. Laden allgemeiner Dateien für die Initialisierung
4. Initialisierung von Session, Authentifizierung und der Berechtigung
5. Laden der Plugin-Konfigurationen
6. Initialisierung des Mandanten und der Sprache, falls nicht vorher geschehen

Unter Punkt 1. wir die Konfiguration des Mandanten (cms/data/config/{umgebungsname}/config.php) geladen und in der steht die Default-Id des Mandanten ($load_client) und der Sprache ($load_lang). Beides wird genutzt, um die Sprache und/oder den Mandanten zu initialisieren, falls nicht vorher geschehen.

Eigentlich ist damit sichergestellt, dass beim Laden der Plugin-Konfigurationen zumindest die $load_lang existiert, die bei Aufruf von Pifa::i18n() auch genutzt wird. Wenn in Punkt 5. die Id der Sprache ($lang) noch nicht gesetzt ist, sollte die Default-Sprache $load_lang genutzt werden. Das macht die Funktion cRegistry::getLanguageId(). In diesem Fall aber scheint es weder $lang zu geben noch $load_lang oder beides hat den Wert 0, was auch nicht sein sollte.

Die Idee, die Initialisierung der Sprach- und Mandant-IDs nach vorne ziehen, ist ein Weg, den man sich auch überlegen kann. Wie ich zuvor angemerkt habe, ändern wir die bisherige Logik und wäre vermutlich nicht abwärtskompatibel. Solche Änderungen sollte man eher in einer Major-Version machen, damit alle, die CONTENIDO nutzen, ggf. ihre Plugins darauf anpassen.

@Bernhard:
Kannst du bitte bei dir prüfen, ob es eine cms/data/config/{umgebungsname}/config.php gibt und falls ja, was da der Wert für die Variable $load_lang ist?
Und kommt der von dir berichtete Fehler oft vor oder ist es bisher nur einmal aufgetaucht?

[Bernhard_4711]

Hallo Murat,
die Datei existiert in cms/data/config/production/ und die Werte sind so besetzt:

Code: Alles auswählen

$load_lang = '1';
$load_client = '1';

Nachtrag (ich werde wohl vergeßlich): Das kam bis jetzt genau einmal vor.

[Bernhard_4711]

ein bisschen Kontext wäre gut. Wann tritt der Fehler auf? Frontend? Backend? Spezielles Plugin?

Diese Fragen kann ich nicht beantworten; ich habe lediglich die Datei "errorlog.txt" mit diesem Inhalt gesehen.

Das ließ mir keine Ruhe und ich konnte das etwas eingrenzen:

Code: Alles auswählen

nn.nnn.nnn.nnn - - [17/Jan/2025:07:04:37 +0100] "GET /remote/login?lang= HTTP/1.1" 500 2962 "https://nn.nnn.nn.nnn:nnn/remote/login?lang=en" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36"
 

Das ist sehr wahrscheinlich der Zugriff auf meine Webseite, der die "Uncaught cInvalidArgumentException" ausgelöst hat. Die IP-Adressen habe ich unkenntlich gemacht und die kam auch nur genau dieses eine Mal vor.
Da wir aktuell Winterzeit haben, steht da "17/Jan/2025:07:04:37 +0100"; im Errorlog "17-Jan-2025 06:04:37 UTC". Soll wohl passen.

[bodil]

Mit Eingrenzen meinte ich eigentlich: was musst du tun, damit diese Art Fehlermeldung erscheint. Aber das geht nicht immer.

[Bernhard_4711]

Mit Eingrenzen meinte ich eigentlich: was musst du tun, damit diese Art Fehlermeldung erscheint.

Ich muß gar nichts tun! Das sind Zugriffe auf meine Webseite, die ich nicht beeinflussen kann.

[xmurrix]

Code: Alles auswählen

nn.nnn.nnn.nnn - - [17/Jan/2025:07:04:37 +0100] "GET /remote/login?lang= HTTP/1.1" 500 2962 "https://nn.nnn.nn.nnn:nnn/remote/login?lang=en" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36"
 

Die http-Anfrage "remote/login?lang=en" könnte das Problem verursachen.

1. Ist kein ModRewrite-Plugin aktiv, liefert es einen 404 Fehler und der Parameter lang=en hat keinen Einfluss

2. Wird ModRewrite genutzt, prüft der cRequestValidator den lang-Parameter, d.h. ein nicht gültiger Wert lang=en wird erkannt. Der cRequestValidator ist standardmäßig so konfiguriert, dass es in so einem Fall die Ausführung des Skriptes beendet, siehe "$sMode = 'stop';" in data/config/{umgebungsnname}/config.http_check.php.

Ist das Loggen für cRequestValidator aktiviert, siehe "$bLog = true;" in data/config/{umgebungsnname}/config.http_check.php, schreibt es erkannte ungültige Parameter in die Log-Datei data/logs/security.txt.

Hat man aber den Modus auf z. B. "$sMode = 'continue';" gesetzt, würde der cRequestValidator auch bei einem fehlerhaften Wert weitermachen. Das kann den Fehler bei dir erklären.

Generell würde ich den cRequestValidator immer so konfigurieren, dass es bei einem ungültigen Wert das Skript beendet. Dies ist die sicherere Lösung, das Beenden des Skriptes kann aber in manchen Fällen unerwünscht sein.

Nachtrag:
Den Fehler kann ich bestätigen. Setze ich in der cRequestValidator Konfiguration den Wert für $sMode wie folgt

Code: Alles auswählen

$sMode = 'continue';

erhalte ich den gleichen Fehler in der errorlog.txt.

[Bernhard_4711]

Code: Alles auswählen

$bLog = true;
$sMode = 'stop';

... beides in /data/config/production/config.http_check.php

[Bernhard_4711]

Die http-Anfrage "remote/login?lang=en" könnte das Problem verursachen.

Solche Anfragen füllen regelmäßig die "security.txt" ...

[Faar]

Generell wird das Security.txt mit Zeug gefüllt, wobei ich mir denke, dass es längst nicht immer um Sicherheitsprobleme oder Angriffe geht.
Zudem ist der Text nicht sehr aussagekräftig, für xmurrix vielleicht aber die meisten können damit nichts anfangen.
Das ist wie bei Windows, wo als Fehlermeldung irgendein Registry Code oder ähnlich angezeigt wird.
Praktisch wurde seit sehr langer Zeit (4.6.13 oder so) nicht eine Seite mehr wirklich gehackt. Wenn, dann lag der Fehler beim Anwender, bzw. auf dessen PC ein Trojaner.

Soll man die security.txt schlicht ignorieren, weil man eh nichts damit anfangen kann?