www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/777b9afe-ca4e-4c74-9a31-5692eda5e066/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

ErrorException: Warning: file_get_contents(https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Hill…

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers¶

1. Ursache identifizieren¶

Der Fehler tritt auf, weil file_get_contents() versucht, eine externe HTTP-Anfrage an die URL
https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Hillemeyer
zu senden, aber der Webservice antwortet mit einem HTTP 500 Internal Server Error.

• Technische Ursache:

  • Die Ziel-URL (rietberg.ratsinfomanagement.net) liefert einen Serverfehler (500) zurück.
  • file_get_contents() kann die Antwort nicht verarbeiten und wirft eine ErrorException.
  • Der Fehler entsteht nicht in TYPO3 selbst, sondern in einem benutzerdefinierten Skript (/public/index.php:21), das den Webservice aufruft.

• Mögliche Gründe für den 500er-Fehler:

  • Der Webservice ist nicht erreichbar (z. B. Wartungsmodus, Firewall-Blockade).
  • Die Parameter (type=3, maxOccurs=-1, terms=Hillemeyer) sind ungültig (z. B. maxOccurs=-1 könnte ein Problem sein).
  • Der Webservice hat intern einen Fehler (z. B. Datenbankproblem, fehlende Berechtigungen).
  • SSL/TLS-Probleme (z. B. Zertifikatsfehler, veraltete Protokolle).
  • Timeout (der Webservice antwortet zu langsam).

2. Fix beschreiben (konkret)¶

Schritt 1: Fehlerquelle isolieren

• Prüfe die URL manuell (z. B. im Browser oder mit curl):

  curl -v "https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Hillemeyer"
  

  • Falls ein 500er-Fehler zurückkommt, liegt das Problem beim Webservice selbst (nicht bei TYPO3).
  • Falls die URL funktioniert, könnte es an PHP-Einstellungen liegen (z. B. allow_url_fopen deaktiviert).

Schritt 2: Robustere Fehlerbehandlung implementieren

• Ersetze file_get_contents() durch GuzzleHttp (empfohlen für TYPO3):

  use GuzzleHttp\Client;
  use GuzzleHttp\Exception\RequestException;
  
  $client = new Client();
  try {
      $response = $client->get('https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch', [
          'query' => [
              'type' => 3,
              'maxOccurs' => -1,
              'terms' => 'Hillemeyer'
          ],
          'timeout' => 10, // Timeout in Sekunden
          'verify' => true // SSL-Zertifikat prüfen
      ]);
      $data = json_decode($response->getBody(), true);
  } catch (RequestException $e) {
      // Logge den Fehler (z. B. mit TYPO3 Logger)
      \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Log\LogManager::class)
          ->getLogger(__CLASS__)
          ->error('Webservice-Aufruf fehlgeschlagen', ['exception' => $e]);
  
      // Fallback-Verhalten (z. B. leere Antwort oder Default-Daten)
      $data = [];
  }
  

Schritt 3: Parameter validieren

• Prüfe, ob maxOccurs=-1 vom Webservice unterstützt wird (manche APIs erlauben keine negativen Werte).
• Falls möglich, teste mit anderen Parametern (z. B. maxOccurs=100).

Schritt 4: PHP-Einstellungen prüfen

• Stelle sicher, dass allow_url_fopen = On in der php.ini aktiviert ist.
• Falls SSL-Probleme vermutet werden:

  // Vorübergehend SSL-Prüfung deaktivieren (nur für Tests!)
  $context = stream_context_create([
      'ssl' => [
          'verify_peer' => false,
          'verify_peer_name' => false,
      ],
  ]);
  $response = file_get_contents($url, false, $context);
  

Schritt 5: Webservice kontaktieren

• Falls der 500er-Fehler reproduzierbar ist, wende dich an den Betreiber von ratsinfomanagement.net und frage nach:
  • Gültigen Parametern für die API.
  • Möglichen Wartungsfenstern.
  • Logs zum Fehler (z. B. Stacktrace des 500er-Fehlers).

3. Betroffene TYPO3 Extension nennen¶

• Der Fehler stammt nicht aus einer TYPO3-Core-Extension, sondern aus einem benutzerdefinierten Skript (/public/index.php).
• Mögliche Extensions, die betroffen sein könnten:
  • Eine selbst entwickelte Extension, die den Webservice aufruft (z. B. für Suchfunktionen).
  • Eine Drittanbieter-Extension, die externe APIs integriert (z. B. ext:news, ext:solr mit Webservice-Anbindung).
  • Falls der Fehler in einem TYPO3-Formular auftritt: Prüfe die Extension ext:form oder eine benutzerdefinierte Formular-Extension.

Empfehlung:

• Suche im Projekt nach file_get_contents( oder GuzzleHttp in /public/index.php oder /typo3conf/ext/.
• Prüfe, ob eine Middleware oder ein CommandController den Webservice aufruft.

4. Confidence (0-100%)¶

Gesamt-Confidence: 85%

• Die Analyse ist sehr wahrscheinlich korrekt, da der Fehler klar auf einen externen Webservice-Aufruf hindeutet.
• Die genaue Ursache des 500er-Fehlers kann nur durch Logs des Webservice-Betreibers oder manuelle Tests bestätigt werden.

Zusammenfassung der nächsten Schritte¶

1. Manuell prüfen, ob die URL einen 500er-Fehler liefert (mit curl oder Browser).
2. Parameter anpassen (z. B. maxOccurs auf einen positiven Wert setzen).
3. file_get_contents() durch GuzzleHttp ersetzen und robuste Fehlerbehandlung implementieren.
4. Logs des Webservice-Betreibers anfordern, falls der Fehler persistiert.
5. TYPO3-Logs prüfen (/var/log/typo3_*.log), ob weitere Hinweise vorhanden sind.