- Willkommen im Forum „moziloCMS Supportforum“.
moziloCMS Supportforum
Neuigkeiten:
moziloCMS verwendet Cookies. Wenn Sie auf unserer Seite weitersurfen, stimmen Sie der Cookie-Nutzung zu Datenschutzerklärung
moziloCMS Layouts
moziloCMS Plugins
Neueste Beiträge
#11
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von Fischi - 02. Juni 2026, 08:27:56Das geänderte HTML entsteht in der fileupload.template.js:
'<div class="delete flex">' +
'<button ...></button>' +
'<label for="">' +
'<span class="sr-only">...</span>' +
'<input id="" type="checkbox" name="delete" value="1" />' +
'</label>' +
'</div>'
Damit ist der Button kein direktes Geschwisterelement der Checkbox mehr.
Direktes Geschwisterelement der Checkbox ist hier nur der vorherige <span> innerhalb des <label>, nicht der <button>.
Das alte .siblings('button') greift nicht mehr; Löschen greift in´s Leere.
Gruß
'<div class="delete flex">' +
'<button ...></button>' +
'<label for="">' +
'<span class="sr-only">...</span>' +
'<input id="" type="checkbox" name="delete" value="1" />' +
'</label>' +
'</div>'
Damit ist der Button kein direktes Geschwisterelement der Checkbox mehr.
Direktes Geschwisterelement der Checkbox ist hier nur der vorherige <span> innerhalb des <label>, nicht der <button>.
Das alte .siblings('button') greift nicht mehr; Löschen greift in´s Leere.
Gruß
#12
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von Fischi - 01. Juni 2026, 21:00:36Ich habe mich mal mit Unterstützung auf die Suche gemacht. Da ist tatsächlich ein Fehler, der schon länger zurückreicht. Irgendwann wurde an der HTML-Struktur was geändert.
In dialog.js gibt es die Funktion function dialog_delete_files().
Es wird angenommen, dass der Löschbutton ein direktes Geschwisterelement der Checkbox ist:
find('.delete input:checked').siblings('button')
Da scheint es in der Vergangenheit wohl eine Veränderung im HTML gegeben zu haben (habe nicht versucht, das zu finden):
In der Funktion dialog_delete_files()
diese Zeile:
del_item[0].find('.delete input:checked').siblings('button').addClass('js-nodialog').click();
ändern in:
del_item[0].find('.delete input:checked').each(function () {
$(this).closest('.delete').find('button').addClass('js-nodialog').trigger('click');
});
hat bei mir das Problem behoben.
Ich hatte schon wieder Bedenken, daß da was in meiner persönlichen Umgebung hakt. Aber es ist ein echter Fehler. Jetzt funktioniert bei mir alles, wie es soll.
Zugegeben - Gruppenlöschen ist nun nicht gerade DIE wichtige Funktion. Wenige haben es bemerkt; man konnte sich ja auch behelfen, indem man 5 Mal Einzellöschung genutzt hat.
Ist vielleicht noch ein Punkt für die Version 3.0.5
Ihr werdet das prüfen.
Gruß
In dialog.js gibt es die Funktion function dialog_delete_files().
Es wird angenommen, dass der Löschbutton ein direktes Geschwisterelement der Checkbox ist:
find('.delete input:checked').siblings('button')
Da scheint es in der Vergangenheit wohl eine Veränderung im HTML gegeben zu haben (habe nicht versucht, das zu finden):
In der Funktion dialog_delete_files()
diese Zeile:
del_item[0].find('.delete input:checked').siblings('button').addClass('js-nodialog').click();
ändern in:
del_item[0].find('.delete input:checked').each(function () {
$(this).closest('.delete').find('button').addClass('js-nodialog').trigger('click');
});
hat bei mir das Problem behoben.
Ich hatte schon wieder Bedenken, daß da was in meiner persönlichen Umgebung hakt. Aber es ist ein echter Fehler. Jetzt funktioniert bei mir alles, wie es soll.
Zugegeben - Gruppenlöschen ist nun nicht gerade DIE wichtige Funktion. Wenige haben es bemerkt; man konnte sich ja auch behelfen, indem man 5 Mal Einzellöschung genutzt hat.
Ist vielleicht noch ein Punkt für die Version 3.0.5
Ihr werdet das prüfen.
Gruß
#13
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von Fischi - 01. Juni 2026, 15:13:05Hallo marusti,
mir ist bei der Verwaltung der Dateien (Bilder) was aufgefallen.
Wenn ich mehrere Bilder löschen will, dann markiere ich diese ganz rechts mit Haken. Die Löschfunktion oben in der Symbolleiste betätigen (Papierkorb als rechtes Symbol), dann wird auch gefragt, ob die markierten Dateien gelöscht werden sollen. Nach Bestätigung sind die Dateien aber noch da. Auch Seite neu laden ändert das nicht.
Auch ein einzelnes Bild über diesen Weg läßt sich nicht löschen.
Wenn ich mich aus dem Admin auslogge und dann wieder anmelde, ist der Punkt Dateien ausgegraut. Ich muß Andere Benutzer abmelden!
Die Einzelbildlöschung über den Papierkorb redhts neben der Datei funktioniert. Aber eben nur Bild für Bild.
Das gleiche Verhalten zeigen auch Version 3.0.4 (auch Version 2.0 Rev55)
Hoffentlich habe ich da nicht was übersehen oder gar falsch gemacht.
Gruß
mir ist bei der Verwaltung der Dateien (Bilder) was aufgefallen.
Wenn ich mehrere Bilder löschen will, dann markiere ich diese ganz rechts mit Haken. Die Löschfunktion oben in der Symbolleiste betätigen (Papierkorb als rechtes Symbol), dann wird auch gefragt, ob die markierten Dateien gelöscht werden sollen. Nach Bestätigung sind die Dateien aber noch da. Auch Seite neu laden ändert das nicht.
Auch ein einzelnes Bild über diesen Weg läßt sich nicht löschen.
Wenn ich mich aus dem Admin auslogge und dann wieder anmelde, ist der Punkt Dateien ausgegraut. Ich muß Andere Benutzer abmelden!
Die Einzelbildlöschung über den Papierkorb redhts neben der Datei funktioniert. Aber eben nur Bild für Bild.
Das gleiche Verhalten zeigen auch Version 3.0.4 (auch Version 2.0 Rev55)
Hoffentlich habe ich da nicht was übersehen oder gar falsch gemacht.
Gruß
#14
Tipps und Tricks / Schutz vor Hostname Spoofing m...
Letzter Beitrag von bernhard_u - 01. Juni 2026, 11:18:14Hallo zusammen,
ich möchte einen wichtigen Tipp zum Thema Sicherheit und Performance mit euch teilen, der besonders für alle relevant ist, die moziloCMS im Shared Hosting (z. B. bei IONOS oder ähnlichen Massenhostern) betreiben.
Problem
Wenn mann z.B. eine .htaccess-Regel hat, um auf HTTPS und das "www." vor der Domain umzuleiten ähnlich wie dieser hier:
Wenn nun ein Angreifer die manipulierte Adresse www.evil.com an deinen Server schickt, fragt die Bedingung: Beginnt www.evil.com nicht mit www.? Nein, sie beginnt ja mit www. (falsch).
Da die Bedingung damit fehlschlägt, wird die sichere Weiterleitung übersprungen. Der Server bricht die Prüfung ab und reicht die manipulierte Fremddomain www.evil.com ungefiltert weiter in das CMS. Ein Angreifer kann dann bei seinem Aufruf einfach einen manipulierten HTTP-Host-Header wie "www.evil.com" mitsenden.
Das birgt im Shared Hosting das Risiko von "Host Header Spoofing", da dort aus Kompatibilitätsgründen fast immer die Apache-Einstellung "UseCanonicalName Off" aktiv ist. Dadurch reicht der Webserver einem manipulierten Host-Header wie ("www.evil.com") ungefiltert an PHP und damit direkt an moziloCMS weiter, was für Phishing-Angriffe oder schädliche Link-Injektionen missbraucht werden kann.
Abhilfe
Hier ist eine optimierte und gehärtete Version für die .htaccess, die dieses Problem radikal löst und gleichzeitig die Ladezeit verbessert ("www.deine-domain.de" muss natürlich gegen die echte Domain getauscht werden):
Was wurde hier genau verbessert?
Maximale Sicherheit gegen Host-Spoofing Die neue Regel prüft exakt gegen deine echte Domain: !^www.deine-domain.de$ (Ist es NICHT exakt meine Domain?). Jeder falsche oder manipulierte Host erzwingt sofort einen harten 301-Redirect auf deine echte Domain, wodurch der schädliche Header weggewaschen wird, bevor Schaden entsteht.
Performance-Schub (1-Step-Redirect statt Ketten) Wer früher "http://meine-domain.de" (ohne HTTPS und ohne www) aufgerufen hat, flog oft durch eine Kette: Erst der Redirect auf HTTPS, dann ein zweiter Redirect auf WWW. Das sind zwei HTTP-Requests, die spürbar auf die Time to First Byte (TTFB) schlagen und die Core Web Vitals verschlechtern. Durch die logische Verknüpfung mit [,OR] in der neuen Version wird jede falsche Kombination in einem einzigen Schritt direkt auf die Ziel-URL korrigiert.
Quellen und weiterführende Informationen für technisch Interessierte:
OWASP Web Security Testing Guide:
Die OWASP beschreibt in diesem Dokument im Detail, wie Angreifer unvalidierte Host-Header ausnutzen können (z. B. für Cache-Poisoning oder die Manipulation von Passwort-Reset-Funktionen). Die dortige Empfehlung besagt klar, dass eine strikte Validierung der Header-Werte stattfinden muss. Da man im Shared Hosting die globale Serverkonfiguration nicht anpassen kann, simulierst unsere .htaccess-Regel genau dieses geforderte Whitelisting:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
PortSwigger Web Security Academy:
Eine exzellente, praxisnahe Aufarbeitung der Angriffsvektoren (wie Cache-Poisoning oder das Einschleusen schädlicher Payloads), die durch unvalidierte Host-Header entstehen, findet sich im Fachbereich der PortSwigger Academy:
https://portswigger.net/web-security/host-header
Beste Grüße und viel Erfolg beim Härten eurer moziloCMS-Installationen!
ich möchte einen wichtigen Tipp zum Thema Sicherheit und Performance mit euch teilen, der besonders für alle relevant ist, die moziloCMS im Shared Hosting (z. B. bei IONOS oder ähnlichen Massenhostern) betreiben.
Problem
Wenn mann z.B. eine .htaccess-Regel hat, um auf HTTPS und das "www." vor der Domain umzuleiten ähnlich wie dieser hier:
Code Auswählen
# ACHTUNG: BEISPIEL FÜR EINE UNSICHERE REGEL!
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.meine-domain.de/$1 [R=301,L]
Die Schwachstelle liegt im Detail: Die Bedingung prüft nur, ob die Eingabe nicht mit www. beginnt.Wenn nun ein Angreifer die manipulierte Adresse www.evil.com an deinen Server schickt, fragt die Bedingung: Beginnt www.evil.com nicht mit www.? Nein, sie beginnt ja mit www. (falsch).
Da die Bedingung damit fehlschlägt, wird die sichere Weiterleitung übersprungen. Der Server bricht die Prüfung ab und reicht die manipulierte Fremddomain www.evil.com ungefiltert weiter in das CMS. Ein Angreifer kann dann bei seinem Aufruf einfach einen manipulierten HTTP-Host-Header wie "www.evil.com" mitsenden.
Das birgt im Shared Hosting das Risiko von "Host Header Spoofing", da dort aus Kompatibilitätsgründen fast immer die Apache-Einstellung "UseCanonicalName Off" aktiv ist. Dadurch reicht der Webserver einem manipulierten Host-Header wie ("www.evil.com") ungefiltert an PHP und damit direkt an moziloCMS weiter, was für Phishing-Angriffe oder schädliche Link-Injektionen missbraucht werden kann.
Abhilfe
Hier ist eine optimierte und gehärtete Version für die .htaccess, die dieses Problem radikal löst und gleichzeitig die Ladezeit verbessert ("www.deine-domain.de" muss natürlich gegen die echte Domain getauscht werden):
Code Auswählen
RewriteEngine On
RewriteBase /
# 1. SCHUTZ VOR HOST-SPOOFING & HTTPS/WWW-ZWANG
# Wenn der Host NICHT exakt deine Domain ist OR HTTPS aus ist...
RewriteCond %{HTTP_HOST} !^www\.deine-domain\.de$ [NC,OR]
RewriteCond %{HTTPS} off
# ...dann jage ALLES sofort auf die korrekte, sichere URL.
# Das wäscht jeden gefälschten Host-Header sauber, bevor er mozilo erreicht.
RewriteRule ^(.*)$ https://www.deine-domain.de/$1 [L,R=301]
# 2. Mozilo Standard-Regeln (unverändert, aber sauber getrennt)
# mozilo_start
...
...
# mozilo_end
Was wurde hier genau verbessert?
Maximale Sicherheit gegen Host-Spoofing Die neue Regel prüft exakt gegen deine echte Domain: !^www.deine-domain.de$ (Ist es NICHT exakt meine Domain?). Jeder falsche oder manipulierte Host erzwingt sofort einen harten 301-Redirect auf deine echte Domain, wodurch der schädliche Header weggewaschen wird, bevor Schaden entsteht.
Performance-Schub (1-Step-Redirect statt Ketten) Wer früher "http://meine-domain.de" (ohne HTTPS und ohne www) aufgerufen hat, flog oft durch eine Kette: Erst der Redirect auf HTTPS, dann ein zweiter Redirect auf WWW. Das sind zwei HTTP-Requests, die spürbar auf die Time to First Byte (TTFB) schlagen und die Core Web Vitals verschlechtern. Durch die logische Verknüpfung mit [,OR] in der neuen Version wird jede falsche Kombination in einem einzigen Schritt direkt auf die Ziel-URL korrigiert.
Quellen und weiterführende Informationen für technisch Interessierte:
OWASP Web Security Testing Guide:
Die OWASP beschreibt in diesem Dokument im Detail, wie Angreifer unvalidierte Host-Header ausnutzen können (z. B. für Cache-Poisoning oder die Manipulation von Passwort-Reset-Funktionen). Die dortige Empfehlung besagt klar, dass eine strikte Validierung der Header-Werte stattfinden muss. Da man im Shared Hosting die globale Serverkonfiguration nicht anpassen kann, simulierst unsere .htaccess-Regel genau dieses geforderte Whitelisting:
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection
PortSwigger Web Security Academy:
Eine exzellente, praxisnahe Aufarbeitung der Angriffsvektoren (wie Cache-Poisoning oder das Einschleusen schädlicher Payloads), die durch unvalidierte Host-Header entstehen, findet sich im Fachbereich der PortSwigger Academy:
https://portswigger.net/web-security/host-header
Beste Grüße und viel Erfolg beim Härten eurer moziloCMS-Installationen!
#15
Hier klemmt es! / Antw:Admin Speichern unter STR...
Letzter Beitrag von Fischi - 30. Mai 2026, 20:48:35Ich denke, ich habe da eine Spur. Kann ja nur in meinem Netz sein. Vermutlich Hyper-V und IPv6.
Nur mal als Anmerkung. Wird für die Meisten sowieso nicht relevant sein.
Gruß
Nur mal als Anmerkung. Wird für die Meisten sowieso nicht relevant sein.
Gruß
#16
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von bernhard_u - 30. Mai 2026, 10:54:21Vielen Dank für das ausführliche Feedback und den Screenshot – das hat sehr geholfen, das Problem genau zu verstehen!
Mit Version 1.3.4 wurde die Meldung präzisiert. Statt "PLUGIN DEAKTIVIERT" erscheint nun "SEO-URLs inaktiv" – denn das Plugin selbst bleibt aktiv, nur die Slug-Umleitung ist ausgesetzt. Sobald die .htaccess korrekt konfiguriert ist, nimmt das Plugin den Betrieb automatisch wieder auf – kein erneutes Aktivieren im Admin nötig.
Den Widerspruch bei der Versionsangabe "2.0 / 3.0" habe ich ebenfalls adressiert: direkt in der Voraussetzungen-Tabelle im Admin-Bereich erklärt warum die "2" im Versionsstring technisch erforderlich ist, obwohl moziloCMS 2.x nicht unterstützt wird (wenn das Problem im CMS Kern gefixt ist, kann man die korrekte Anagebe zur Version machen).
Noch eine Bitte für künftige Fehlerberichte: das Mitschicken der .htaccess-Konfiguration (oder zumindest der relevanten RewriteRule-Blöcke) erleichtert die Analyse erheblich und hilft dabei, das Problem schneller einzugrenzen.
Das Update ist auf GitHub verfügbar: https://github.com/bernhardunger/moziloCMS_seo_plugin
Mit Version 1.3.4 wurde die Meldung präzisiert. Statt "PLUGIN DEAKTIVIERT" erscheint nun "SEO-URLs inaktiv" – denn das Plugin selbst bleibt aktiv, nur die Slug-Umleitung ist ausgesetzt. Sobald die .htaccess korrekt konfiguriert ist, nimmt das Plugin den Betrieb automatisch wieder auf – kein erneutes Aktivieren im Admin nötig.
Den Widerspruch bei der Versionsangabe "2.0 / 3.0" habe ich ebenfalls adressiert: direkt in der Voraussetzungen-Tabelle im Admin-Bereich erklärt warum die "2" im Versionsstring technisch erforderlich ist, obwohl moziloCMS 2.x nicht unterstützt wird (wenn das Problem im CMS Kern gefixt ist, kann man die korrekte Anagebe zur Version machen).
Noch eine Bitte für künftige Fehlerberichte: das Mitschicken der .htaccess-Konfiguration (oder zumindest der relevanten RewriteRule-Blöcke) erleichtert die Analyse erheblich und hilft dabei, das Problem schneller einzugrenzen.
Das Update ist auf GitHub verfügbar: https://github.com/bernhardunger/moziloCMS_seo_plugin
#17
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von hheigl - 29. Mai 2026, 23:32:30Hallo bernhard_u,
vielen Dank für das Bugfix-Release v1.3.3.
Nachdem ich ja nunmehr weiß, dass moziloCMS 2.x nicht unterstützt wird, habe ich es mit dieser Konstellation nicht weiter versucht.
Mit der moziloCMS-Version 3.04 habe ich zunächst die Plugin-Version 1.3.1 deinstalliert und dann die neue Plugin-Version 1.3.3 installiert und aktiviert.
Im Plugin-Adminbereich hat mir der blaue Schiebeschalter in der rechten oberen Ecke angezeigt, dass das Plugin aktiviert ist.
Die rote Information, die mir zum _seo_urls angezeit wurde, sagte jedoch das Gegenteil aus! (siehe Anhang mit dem Warnhinweis "PLUGIN DEAKTIVIERT")
Ein Aufruf der Homepageseite -und auch der weiteren Inhaltsseiten- funktionierte jedoch.
Aufgrund der Pfadangaben, die mir in der URL angezeigt werden, gehe ich jedoch davon aus, dass das Plugin aufgrund der neu eingebauten Prüfroutine tatsächlich deaktiviert ist
(obwohl der blaue Schiebeschalter eigentlich gegenteiliges vermuten lässt).
Einen weiteren Hinweis hätte ich auch noch anzubringen: Als benötigte moziloCMS-Version wird angegeben: "2.0 / 3.0"
In den Voraussetzungen, die etwas weiter unten stehen, wird jedoch angegeben, dass die moziloCMS-Version 2.x nicht unterstützt wird.
Diese beiden Aussagen widersprechen sich meiner Meinung nach!
Ich glaube, da sind noch einige Nacharbeiten notwendig!
vielen Dank für das Bugfix-Release v1.3.3.
Nachdem ich ja nunmehr weiß, dass moziloCMS 2.x nicht unterstützt wird, habe ich es mit dieser Konstellation nicht weiter versucht.
Mit der moziloCMS-Version 3.04 habe ich zunächst die Plugin-Version 1.3.1 deinstalliert und dann die neue Plugin-Version 1.3.3 installiert und aktiviert.
Im Plugin-Adminbereich hat mir der blaue Schiebeschalter in der rechten oberen Ecke angezeigt, dass das Plugin aktiviert ist.
Die rote Information, die mir zum _seo_urls angezeit wurde, sagte jedoch das Gegenteil aus! (siehe Anhang mit dem Warnhinweis "PLUGIN DEAKTIVIERT")
Ein Aufruf der Homepageseite -und auch der weiteren Inhaltsseiten- funktionierte jedoch.
Aufgrund der Pfadangaben, die mir in der URL angezeigt werden, gehe ich jedoch davon aus, dass das Plugin aufgrund der neu eingebauten Prüfroutine tatsächlich deaktiviert ist
(obwohl der blaue Schiebeschalter eigentlich gegenteiliges vermuten lässt).
Einen weiteren Hinweis hätte ich auch noch anzubringen: Als benötigte moziloCMS-Version wird angegeben: "2.0 / 3.0"
In den Voraussetzungen, die etwas weiter unten stehen, wird jedoch angegeben, dass die moziloCMS-Version 2.x nicht unterstützt wird.
Diese beiden Aussagen widersprechen sich meiner Meinung nach!
Ich glaube, da sind noch einige Nacharbeiten notwendig!
#18
Plugins / Antw:Automatische SEO-URLs in ...
Letzter Beitrag von bernhard_u - 29. Mai 2026, 14:22:24Hallo zusammen,
es gibt nun seo_urls v1.3.3 ein Bugfix-Release.
Kleine aber feine Verbesserungen auf Basis eines Code-Reviews:
GitHub: https://github.com/bernhardunger/moziloCMS_seo_plugin
es gibt nun seo_urls v1.3.3 ein Bugfix-Release.
Kleine aber feine Verbesserungen auf Basis eines Code-Reviews:
- Erweiterte .htaccess-Prüfung: Sitemap-Regel wird jetzt ebenfalls geprüft, auskommentierte Regeln werden korrekt als inaktiv erkannt, im Fehlerfall werden die erforderlichen Regeln direkt im Admin angezeigt.
- Bugfix: Großakzente wie É, À wurden bisher nicht korrekt transliteriert ("CAFÉ" wird jetzt korrekt zu "cafe"). Betrifft alle Versionen vor v1.3.3.
- Sicherheit: unserialize() gehärtet, Header-Injection-Schutz in redirect().
- Robustheit: rewriteOutput()-Regex explizit erweitert, PLUGIN_DIR-Fallback abgesichert.
GitHub: https://github.com/bernhardunger/moziloCMS_seo_plugin
#19
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von bernhard_u - 28. Mai 2026, 11:36:48Hallo Maik,
ja genau: "Die Anleitung gilt für Updates:
von moziloCMS 3.x auf eine andere moziloCMS 3.x Version, Schritte 1 bis 6
Ich habe gerade noch gesehen, dass ein Eintrag für die Startkategorie übernommen wurde, alle anderen die in der Vorversion konfiguriert waren fehlen (Siehe Screenshot).
Viele Grüße
Bernhard
ja genau: "Die Anleitung gilt für Updates:
von moziloCMS 3.x auf eine andere moziloCMS 3.x Version, Schritte 1 bis 6
Ich habe gerade noch gesehen, dass ein Eintrag für die Startkategorie übernommen wurde, alle anderen die in der Vorversion konfiguriert waren fehlen (Siehe Screenshot).
Viele Grüße
Bernhard
#20
Neue Versionen / Antw:mozilo 3.0.5 beta 1
Letzter Beitrag von marusti - 28. Mai 2026, 09:39:15Zitat von: bernhard_u am 27. Mai 2026, 16:27:45bei den Einstellung fehlen die vor dem Update vorhanden Einträge (siehe Screenshot)Hallo bernhard,
Kann man die vorher sichern?
wie hast du das Update durchgeführt? So wie hier? https://www.mozilo.de/Anleitung/Los%20gehts.html