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

Fishpoke: Fishpoke verschob die Seite CLM:Technische Details:Sicherheit und Härtung von Joomla-Installationen nach CLM:Sicherheit und Betrieb:Joomla-Sicherheit und Akeeba Admin Tools: Falsch einsortiert

2026-07-05T07:36:56Z

Fishpoke verschob die Seite CLM:Technische Details:Sicherheit und Härtung von Joomla-Installationen nach CLM:Sicherheit und Betrieb:Joomla-Sicherheit und Akeeba Admin Tools: Falsch einsortiert

← Nächstältere Version		Version vom 5. Juli 2026, 07:36 Uhr
(kein Unterschied)

Fishpoke am 5. Juli 2026 um 07:06 Uhr

2026-07-05T07:06:20Z

← Nächstältere Version		Version vom 5. Juli 2026, 07:06 Uhr
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>.

Fishpoke: Dokumentation: Admin-Tools-403 bei direkter CLM-API

2026-07-05T07:00:15Z

Dokumentation: Admin-Tools-403 bei direkter CLM-API

Neue Seite

= 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:

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

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

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

Die Antwort ist typischerweise eine allgemeine Serverfehlerseite:

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

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:

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

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:

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

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:

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

Sie gehört in den Bereich:

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

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

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

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]]