Beiträge

seo_urls v1.3.7 ist released – ein kleines, aber feines Update das vor allem auf das Feedback aus dem Forum eingeht.
Geändert gegenüber v1.3.6: Die Admin-Sprachdateien folgen jetzt der moziloCMS-Konvention (admin_language_deDE.txt / admin_language_enEN.txt), die Admin-Anzeige ist vollständig zweisprachig und das h4-Element in der Admin-Info wurde durch b ersetzt.
Download: https://github.com/bernhardunger/moziloCMS_seo_plugin/releases

seo_urls v1.3.6 ist verfügbar: https://github.com/bernhardunger/moziloCMS_seo_plugin/releases/tag/v1.3.6

Das Update bringt drei Neuerungen: Der Plugin-Info-Tab im moziloCMS-Backend erscheint jetzt in der eingestellten Backendsprache – aktuell Deutsch und Englisch, Fallback auf Deutsch. Außerdem wurde die interne Kapselung der MetaKeywordsDescription-Kompatibilität verbessert, sodass zukünftige Formatänderungen des Fremd-Plugins nur an einer Stelle angepasst werden müssen. Dazu ein kleiner Fix in der Redirect-Logik.
Das Plugin-ZIP (nur der _seo_urls/-Ordner, bereinigt um Entwicklungsdateien) steht direkt im Release zum Download bereit.

Hallo Maik, danke für deine Rückmeldung. Der bestehende Backup-Hinweis ist auf jeden Fall ein guter erster Schritt. Ich hätte folgenden ergänzenden Vorschlag mit konkretem Hinweis speziell auf die conf-Verzeichnisse z.B.:

Hinweis: Die Verzeichnisse admin/conf/ und cms/conf/ enthalten alle individuellen Konfigurationseinstellungen und sind nicht im Update-ZIP enthalten. Beim FTP-Upload sollten diese Verzeichnisse erhalten bleiben. Fehlen sie nach dem Upload aus irgendeinem Grund, müssen sie vor dem Aufruf von install.php aus dem Backup zurückgespielt werden - andernfalls werden beim Installationsvorgang alle Einstellungen auf Standardwerte zurückgesetzt.

Optional und längerfristig wäre m.E. zudem eine Absicherung direkt im Code von makeConfFiles() sinnvoll: Wenn die conf-Verzeichnisse fehlen obwohl bereits Kategorien auf dem Server existieren, könnte der Wizard eine klare Fehlermeldung ausgeben statt kommentarlos Default-Werte zu schreiben.

Viele Grüße

Bernhard

Hallo,

vielen Dank für die Klärung und den Vorschlag – das ist eine elegante Lösung!

Ich habe den Fix lokal getestet und kann bestätigen: er funktioniert wie beschrieben. Mit dem angepassten Versionscheck wird '3.0' korrekt als moziloCMS 3.x-Plugin erkannt und das Plugin wird nicht mehr automatisch deaktiviert.

Sobald der Fix in einer stabilen moziloCMS-Version landet, werde ich den Versionsstring in seo_urls von '2.0 / 3.0' auf das sauberere '3.0' umstellen. Kannst du mich kurz informieren wenn das der Fall ist?

Bis dahin bleibt '2.0 / 3.0' als Workaround drin – funktioniert ja zuverlässig mit beiden CMS-Versionen.

Viele Grüße
Bernhard

[nicht reproduzieren]

Update zur FTP-Hypothese:

Ich konnte das Problem mit FileZilla 3.69.6 beim zweiten Versuch nicht reproduzieren - die Konfigurationsdaten blieben beim erneuten FTP-Upload korrekt erhalten. FileZilla löscht im Standard-Modus keine Remote-Verzeichnisse, die lokal nicht vorhanden sind - admin/conf/ und cms/conf/ bleiben also normalerweise unangetastet.

Die genaue Ursache des ursprünglichen Problems ist damit noch ungeklärt. Möglicherweise wurde beim ersten Test versehentlich eine andere Aktion ausgeführt.

Der beschriebene Code-Mechanismus in makeConfFiles() bleibt aber grundsätzlich ein Risiko: Wenn die conf-Verzeichnisse aus irgendeinem Grund fehlen, werden kommentarlos Default-Werte geschrieben - ohne Warnung, ohne Rückfrage. Eine Absicherung im Code oder zumindest ein expliziter Hinweis in der Update-Anleitung wäre daher weiterhin sinnvoll.

[Was vermutlich passiert:]

Hallo,

ích habe das Problem der fehlenden Admin-Konfigurationen nach dem Update von 3.0.4 auf 3.0.5 beta näher analysiert - hier eine erste Einschätzung, die aber noch weiter verifiziert werden sollte.

Was vermutlich passiert:
Die Konfigurationsdateien in admin/conf/ und cms/conf/ sind bewusst nicht im Update-ZIP enthalten - sie sollen beim Upload erhalten bleiben. Eine mögliche Ursache für den Verlust könnte jedoch sein, dass ein FTP-Client im Sync-/Mirror-Modus diese Ordner löscht, weil er sie lokal nicht vorfindet und den Server mit dem lokalen Stand "angleicht" - das ist aber noch eine Hypothese und müsste gezielt geprüft werden.

Wenn danach install.php aufgerufen wird, legt die Funktion makeConfFiles() (install.php) die fehlenden Verzeichnisse neu an und schreibt automatisch Default-Werte - die individuellen Einstellungen sind damit überschrieben.

Der kritische Code-Pfad in der install.php:

Code Auswählen Erweitern

if(!is_dir(BASE_DIR_ADMIN.CONF_DIR_NAME))
    mkdir(BASE_DIR_ADMIN.CONF_DIR_NAME);  // leeres Verzeichnis angelegt
if(!is_dir(BASE_DIR_CMS.CONF_DIR_NAME))
    mkdir(BASE_DIR_CMS.CONF_DIR_NAME);   // leeres Verzeichnis angelegt

Danach greift dieser Zweig:

Code Auswählen Erweitern

elseif(is_file($dir))
    continue;          // Datei vorhanden -> überspringen (OK)
else
    $conf = makeDefaultConf($name, true);  // Datei fehlt -> Defaults werden geschrieben!

Warum wirkt die Startkategorie erhalten?
Auch sie wird auf den Default 'Willkommen' zurückgesetzt. Da diese Kategorie auf dem Testserver nicht existiert, zeigt das Dropdown einfach den ersten verfügbaren Eintrag - das erweckt nur den Eindruck, der Wert sei erhalten geblieben.

Sofortmaßnahme / Workaround:
Vor jedem Update die Ordner admin/conf/ und cms/conf/ separat per FTP sichern. Beim Upload keinen Sync-/Mirror-Modus verwenden. Nach dem Upload prüfen, ob beide Ordner noch vorhanden sind - erst dann install.php aufrufen.

Noch eine Ergänzung:

In der Online-Anleitung auf mozilo.de sowie im install.php-Wizard wird beim 1.12 -> 3.x Migrationspfad explizit darauf hingewiesen, alle .conf-Dateien aus admin/conf/ und cms/conf/ zu sichern. Für den 3.x -> 3.x Update fehlt ein solcher Hinweis jedoch - weder in der Update-Anleitung auf mozilo.de noch im Wizard wird erwähnt, dass diese Verzeichnisse beim FTP-Upload erhalten bleiben müssen. Eine ergänzende Warnung sowohl in der Online-Anleitung als auch im Wizard würde das Problem vermutlich verhindern.

Dies ist eine erste Code-Analyse ohne direktes Testen auf einem Live-System. Eine endgültige Bestätigung und ein sauberer Fix im Code oder in der Update-Anleitung sollten durch die Entwickler erfolgen.

Hoffe, das hilft als Hinweis weiter!
Viele Grüße

Bernhard

Hallo,

vielen Dank für dein Feedback – ich habe das jetzt genauer untersucht und kann die Ursache erklären.

Der moziloCMS Plugin-Loader von 3.0.5 beta prüft in admin/plugins.php (Z. 239–266) den Versionsstring aus getInfo() so:

$pl_ver = 0;
if (!empty($plugin_info[1])) {
    $needed_mozilo_version = $plugin_info[1];
} else {
    $pl_ver = 1;
}
$pos = strpos($needed_mozilo_version, '1.1');
if ($pos !== false) {
    $pl_ver = 1;
}
$pos = strpos($needed_mozilo_version, '2');
if ($pos !== false) {
    $pl_ver = 2;
}
if ($pl_ver < 2) {
    // Plugin wird als 1.x erkannt und automatisch deaktiviert
}

Der String wird also mit strpos() auf '2' geprüft – enthält er keine '2', wird das Plugin als moziloCMS 1.x-Version eingestuft und automatisch deaktiviert. Das erklärt warum '3.0' allein nicht funktioniert.

Der Versionsstring '2.0 / 3.0' ist in v1.3.4 und v1.3.5 des seo_url Plugins identisch und enthält die benötigte '2' – der einzige Unterschied zwischen den beiden Versionen in getInfo() ist die Array-Syntax (array() vs. []). Kannst du nochmal prüfen welche Version du ursprünglich installiert hattest? Falls du tatsächlich v1.3.5 verwendet hast und [] das Problem war, wäre das ein CMS-seitiger Bug den ich gerne weiterverfolgen würde.

Viele Grüße
Bernhard

[Problem]

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

Code Auswählen Erweitern

# 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 Erweitern

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!

Vielen 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

Hallo zusammen,

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

Hallo 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

Dieser Fehler ist mit bei der Plugin-Versions Prüfung aufgefallen, das ist auch schon in der V3.0.4 so. Ist das schon bekannt?

moziloCMS prüft ob '2' im Info-String des Plugins enthalten ist. Fehlt die '2', deaktiviert der Admin das Plugin automatisch.   
Die Logik ist in admin/plugins.php Zeilen 246-255:
$pl_ver = 0;
$pos = strpos($needed_mozilo_version, '1.1');
if ($pos !== false) {
    $pl_ver = 1;
}
$pos = strpos($needed_mozilo_version, '2');
if ($pos !== false) {
    $pl_ver = 2;
}
if ($pl_ver < 2) {
    // Fehlermeldung + Plugin wird automatisch deaktiviert!
}

Das Ergebnis: Der Versionsstring muss die Ziffer '2' enthalten – sonst deaktiviert moziloCMS das Plugin automatisch. Es gibt keine Prüfung auf '3' alleine, also wenn das Plugin nicht 2.x kompatibel ist muss mann trotzdem *2.0 /3.0' in den Info String eintragen, sonst kommt eine Fehlermeldung.
Beispiel:
 $info = array(
            '<b>seo_urls</b> ' . self::VERSION,
            '2.0 / 3.0',  // Hinweis: moziloCMS prüft ob '2' im String enthalten ist.
            // Fehlt die '2', deaktiviert der Admin das Plugin automatisch.
            // Das Plugin unterstützt nur moziloCMS 3.0.x – siehe getInfo().
            $description,
            '',
            '',
            array('seo', 'url', 'rewrite', 'slug')
        );

bei den Einstellung fehlen die vor dem Update vorhanden Einträge (siehe Screenshot)
Kann man die vorher sichern?

Hallo marusti,

ich habe die 3.0.5 Beta in einem Testbereich installiert, hier mein Feedback:
Der Fehler ist behoben:
###CMS
Fehler bei CANONICAL_LINK behoben https://www.mozilo.de/forum/index.php/topic,4860

SEO_URL und indexnow Plug funktionieren mit 3.0.5 Beta.

Sonst ist mir bei einem ersten schnellen Tests nichts aufgefallen.
Falls ich noch was finde, poste ich es hier.

Viele Grüße

Vielen Dank für die ausführliche Rückmeldung!

Zu Versuch 1 (moziloCMS 2.0 / PHP 7.0): Das Plugin setzt PHP 8.1 und moziloCMS 3.0.x voraus – ältere Versionen werden nicht unterstützt. Ab v1.3.1 ist das im Admin-Bereich klar dokumentiert.

Zu Versuch 2 (moziloCMS 3.0.4 / PHP 8.2): Die fehlende "Not Found"-Meldung war auf fehlende Catch-All-Regeln in der .htaccess zurückzuführen. Ab v1.3.1 prüft das Plugin beim Start ob die .htaccess korrekt konfiguriert ist. Fehlen die Regeln, deaktiviert sich das Plugin automatisch und zeigt im Admin-Bereich einen roten Hinweis mit Erklärung.

Den Hinweis zur template.html habe ich ebenfalls aufgenommen – das Plugin muss nur im Admin-Bereich aktiviert werden, kein weiterer Eintrag im Template nötig.

v1.3.1 ist verfügbar: https://github.com/bernhardunger/moziloCMS_seo_plugin