Quelltext der Seite 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:

<pre>
DataTables warning: table id=DataTables_Table_0 - Ajax error.
</pre>

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

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

Die Antwort ist typischerweise eine allgemeine Serverfehlerseite:

<pre>
Server Error
403 Forbidden
You do not have permission to access this document.
</pre>

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:

<pre>
components/com_clm/clm/index.php
</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>.

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 <code>.htaccess</code> 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 ===

# Joomla-Backend öffnen.
# Zu '''Komponenten → Admin Tools → .htaccess Maker''' gehen.
# Zum Abschnitt '''Exceptions from Server Protection''' scrollen.
# Im obersten Bereich '''Allow direct access to these files''' auf das grüne '''+''' klicken.
# In die neu angelegte Zeile exakt diesen relativen Pfad eintragen:

<pre>
components/com_clm/clm/index.php
</pre>

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

# In der Werkzeugleiste '''Save and Create .htaccess''' ausführen.
# Die betroffene CLM-Seite mit <code>Strg + F5</code> vollständig neu laden.
# 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:

<pre>
components/com_clm/clm
</pre>

Sie gehört in den Bereich:

<pre>
Allow direct access, including .php files, to these directories
</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:

# Datei-Ausnahme für <code>components/com_clm/clm/index.php</code> setzen.
# Ordner-Ausnahme <code>components/com_clm/clm</code> wieder entfernen.
# Danach erneut '''Save and Create .htaccess''' ausführen und CLM testen.

== Was nicht getan werden sollte ==

* Die Server Protection nicht dauerhaft deaktivieren.
* Nicht pauschal <code>components/com_clm</code> 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 ==

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

Eine Kombination aus

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

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

== 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 <code>com_ajax</code>. Dann kann die Ausnahme für die direkte PHP-Datei wieder entfernt werden.

== Quellen ==

* [https://www.akeeba.com/documentation/admin-tools-joomla/server-protection.html Akeeba Admin Tools: Server Protection] – Beschreibung der Sperre direkter PHP-Aufrufe und der empfohlenen dateigenauen Ausnahme.
* [https://www.akeeba.com/documentation/admin-tools-joomla/htaccess-maker.html Akeeba Admin Tools: .htaccess Maker]

[[Kategorie:CLM]]
[[Kategorie:Joomla]]
[[Kategorie:Administration]]
[[Kategorie:Sicherheit]]