CLM:Sicherheit und Betrieb:Joomla-Sicherheit und Akeeba Admin Tools

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

• Akeeba Admin Tools: Server Protection – Beschreibung der Sperre direkter PHP-Aufrufe und der empfohlenen dateigenauen Ausnahme.
• Akeeba Admin Tools: .htaccess Maker