CLM:Sicherheit und Betrieb:Joomla-Sicherheit und Akeeba Admin Tools: Unterschied zwischen den Versionen

Aus ChessLeagueManager
Zur Navigation springen Zur Suche springen
VisuellWikitext
(Dokumentation: Admin-Tools-403 bei direkter CLM-API)
 
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 11: Zeile 11:
Im Browser erscheint beispielsweise:
Im Browser erscheint beispielsweise:


<syntaxhighlight lang="text">
<pre>
DataTables warning: table id=DataTables_Table_0 - Ajax error.
DataTables warning: table id=DataTables_Table_0 - Ajax error.
</syntaxhighlight>
</pre>


In den Browser-Entwicklerwerkzeugen (''Netzwerk'' → ''Fetch/XHR'') ist ein fehlgeschlagener POST-Aufruf zu sehen, zum Beispiel:
In den Browser-Entwicklerwerkzeugen (''Netzwerk'' → ''Fetch/XHR'') ist ein fehlgeschlagener POST-Aufruf zu sehen, zum Beispiel:


<syntaxhighlight lang="text">
<pre>
POST /components/com_clm/clm/index.php?option=com_clm&view=view_tournament&clm_backend=1&session_language=de-DE
POST /components/com_clm/clm/index.php?option=com_clm&view=view_tournament&clm_backend=1&session_language=de-DE
HTTP 403 Forbidden
HTTP 403 Forbidden
</syntaxhighlight>
</pre>


Die Antwort ist typischerweise eine allgemeine Serverfehlerseite:
Die Antwort ist typischerweise eine allgemeine Serverfehlerseite:


<syntaxhighlight lang="text">
<pre>
Server Error
Server Error
403 Forbidden
403 Forbidden
You do not have permission to access this document.
You do not have permission to access this document.
</syntaxhighlight>
</pre>


Im Plesk-Zugriffsprotokoll steht derselbe Aufruf mit Status ''403''. Im ''Blocked Requests Log'' von Admin Tools erscheint dagegen häufig kein neuer Eintrag.
Im Plesk-Zugriffsprotokoll steht derselbe Aufruf mit Status ''403''. Im ''Blocked Requests Log'' von Admin Tools erscheint dagegen häufig kein neuer Eintrag.
Zeile 36: Zeile 36:
CLM lädt Teile der Turnieransichten per Ajax über die Datei:
CLM lädt Teile der Turnieransichten per Ajax über die Datei:


<syntaxhighlight lang="text">
<pre>
components/com_clm/clm/index.php
components/com_clm/clm/index.php
</syntaxhighlight>
</pre>


Dies ist ein direkter Aufruf einer PHP-Datei im Komponentenverzeichnis – also nicht der normale Joomla-Aufruf über die zentrale Datei <code>/index.php</code>.
Dies ist ein direkter Aufruf einer PHP-Datei im Komponentenverzeichnis – also nicht der normale Joomla-Aufruf über die zentrale Datei <code>/index.php</code>.
Zeile 56: Zeile 56:
# In die neu angelegte Zeile exakt diesen relativen Pfad eintragen:
# In die neu angelegte Zeile exakt diesen relativen Pfad eintragen:


<syntaxhighlight lang="text">
<pre>
components/com_clm/clm/index.php
components/com_clm/clm/index.php
</syntaxhighlight>
</pre>


Keinen führenden und keinen abschließenden Schrägstrich eintragen.
Keinen führenden und keinen abschließenden Schrägstrich eintragen.
Zeile 70: Zeile 70:
Als erster Schnellfix kann die Ordnerfreigabe funktionieren:
Als erster Schnellfix kann die Ordnerfreigabe funktionieren:


<syntaxhighlight lang="text">
<pre>
components/com_clm/clm
components/com_clm/clm
</syntaxhighlight>
</pre>


Sie gehört in den Bereich:
Sie gehört in den Bereich:


<syntaxhighlight lang="text">
<pre>
Allow direct access, including .php files, to these directories
Allow direct access, including .php files, to these directories
</syntaxhighlight>
</pre>


Diese Variante ist jedoch weiter gefasst: Sie nimmt alle Dateien dieses Ordners und seiner Unterordner aus der Server Protection heraus. Daher sollte sie nach erfolgreichem Test durch die oben beschriebene, dateigenaue Freigabe ersetzt werden:
Diese Variante ist jedoch weiter gefasst: Sie nimmt alle Dateien dieses Ordners und seiner Unterordner aus der Server Protection heraus. Daher sollte sie nach erfolgreichem Test durch die oben beschriebene, dateigenaue Freigabe ersetzt werden:
Zeile 106: Zeile 106:
Eine Kombination aus
Eine Kombination aus


<syntaxhighlight lang="text">
<pre>
POST /components/.../*.php → 403
POST /components/.../*.php → 403
allgemeine Server-Fehlerseite
allgemeine Server-Fehlerseite
kein passender Eintrag im Admin-Tools-WAF-Log
kein passender Eintrag im Admin-Tools-WAF-Log
</syntaxhighlight>
</pre>


ist ein starker Hinweis auf die ''Server Protection'' der von Admin Tools erzeugten <code>.htaccess</code>.
ist ein starker Hinweis auf die ''Server Protection'' der von Admin Tools erzeugten <code>.htaccess</code>.

Aktuelle Version vom 5. Juli 2026, 07:36 Uhr

CLM / DataTables: Ajax-Fehler 403 nach Aktivierung von Akeeba Admin Tools

Kurzfassung

Nach dem Aktivieren bzw. Neugenerieren der Server Protection im Admin Tools .htaccess Maker kann die CLM-Komponente mit einer DataTables-Meldung ausfallen. Ursache ist nicht DataTables selbst: Eine ältere CLM-Ajax-Anfrage ruft einen PHP-Endpunkt innerhalb der Komponente direkt auf. Die Server Protection blockiert diesen Aufruf bereits auf Webserver-Ebene mit HTTP-Status 403.

Die saubere Lösung ist eine möglichst enge Ausnahme für genau diese PHP-Datei – nicht das Abschalten der Server Protection und nicht die Freigabe der gesamten Komponente.

Fehlerbild

Im Browser erscheint beispielsweise: 

DataTables warning: table id=DataTables_Table_0 - Ajax error.

In den Browser-Entwicklerwerkzeugen (Netzwerk → Fetch/XHR) ist ein fehlgeschlagener POST-Aufruf zu sehen, zum Beispiel: 

POST /components/com_clm/clm/index.php?option=com_clm&view=view_tournament&clm_backend=1&session_language=de-DE
HTTP 403 Forbidden

Die Antwort ist typischerweise eine allgemeine Serverfehlerseite: 

Server Error
403 Forbidden
You do not have permission to access this document.

Im Plesk-Zugriffsprotokoll steht derselbe Aufruf mit Status 403. Im Blocked Requests Log von Admin Tools erscheint dagegen häufig kein neuer Eintrag.

Ursache

CLM lädt Teile der Turnieransichten per Ajax über die Datei: 

components/com_clm/clm/index.php

Dies ist ein direkter Aufruf einer PHP-Datei im Komponentenverzeichnis – also nicht der normale Joomla-Aufruf über die zentrale Datei /index.php.

Die Server Protection des Admin Tools .htaccess Maker ist genau dafür gedacht, direkte Zugriffe auf PHP-Dateien zu unterbinden. Die Sperre erfolgt durch die erzeugte .htaccess bereits im Webserver, bevor Joomla und die Admin-Tools-WAF geladen werden. Deshalb gibt es hier in der Regel keinen passenden WAF-Logeintrag.

Ein älterer Logeintrag mit dem Grund Admin Query String kann unabhängig davon auftreten und ist für dieses konkrete Frontend-/CLM-Problem nicht aussagekräftig.

Behebung: gezielte Ausnahme für den CLM-Endpunkt

Empfohlene, engste Freigabe

  1. Joomla-Backend öffnen.
  2. Zu Komponenten → Admin Tools → .htaccess Maker gehen.
  3. Zum Abschnitt Exceptions from Server Protection scrollen.
  4. Im obersten Bereich Allow direct access to these files auf das grüne + klicken.
  5. In die neu angelegte Zeile exakt diesen relativen Pfad eintragen:
components/com_clm/clm/index.php

Keinen führenden und keinen abschließenden Schrägstrich eintragen.

  1. In der Werkzeugleiste Save and Create .htaccess ausführen.
  2. Die betroffene CLM-Seite mit Strg + F5 vollständig neu laden.
  3. Im Browser-Netzwerkmonitor und im Plesk-Protokoll kontrollieren, ob der bisherige 403-Aufruf nun erfolgreich ist (typischerweise HTTP 200).

Falls zuvor der ganze Ordner freigegeben wurde

Als erster Schnellfix kann die Ordnerfreigabe funktionieren: 

components/com_clm/clm

Sie gehört in den Bereich: 

Allow direct access, including .php files, to these directories

Diese Variante ist jedoch weiter gefasst: Sie nimmt alle Dateien dieses Ordners und seiner Unterordner aus der Server Protection heraus. Daher sollte sie nach erfolgreichem Test durch die oben beschriebene, dateigenaue Freigabe ersetzt werden:

  1. Datei-Ausnahme für components/com_clm/clm/index.php setzen.
  2. Ordner-Ausnahme components/com_clm/clm wieder entfernen.
  3. Danach erneut Save and Create .htaccess ausführen und CLM testen.

Was nicht getan werden sollte

  • Die Server Protection nicht dauerhaft deaktivieren.
  • Nicht pauschal components/com_clm oder die gesamte Komponente für direkte PHP-Zugriffe freigeben.
  • Keine WAF-Ausnahme anlegen, solange der Fehler bereits vor Joomla auf Webserver-Ebene entsteht.
  • Nicht allein anhand einer DataTables-Meldung auf einen JavaScript- oder Datenbankfehler schließen.

Fehlersuche bei einem ähnlichen Problem

  1. Betroffene Seite öffnen und F12 drücken.
  2. Zu Netzwerk wechseln und nach Fetch/XHR filtern.
  3. Seite mit Strg + F5 neu laden.
  4. Den fehlerhaften Request öffnen und folgende Informationen notieren:
    • vollständige Request-URL,
    • HTTP-Status,
    • Antworttext.
  5. Parallel in Plesk unter Websites & Domains → Protokolle die aktuelle Zeile zum Fehler suchen.

Eine Kombination aus 

POST /components/.../*.php → 403
allgemeine Server-Fehlerseite
kein passender Eintrag im Admin-Tools-WAF-Log

ist ein starker Hinweis auf die Server Protection der von Admin Tools erzeugten .htaccess.

Langfristige technische Empfehlung

Direkt erreichbare PHP-Endpunkte in Joomla-Erweiterungen sind heute vermeidbar. Langfristig sollte CLM die Ajax-Anfragen über Joomla selbst abwickeln, zum Beispiel über einen Komponenten-Controller oder com_ajax. Dann kann die Ausnahme für die direkte PHP-Datei wieder entfernt werden.

Quellen

Abgerufen von „https://wiki.chessleaguemanager.org/index.php?title=CLM:Sicherheit_und_Betrieb:Joomla-Sicherheit_und_Akeeba_Admin_Tools&oldid=176“