RealUrl Datenbereinigung

Speziell ältere Versionen von RealURL hatten die Eigenschaft, alle möglichen URLs zu speichern, die Benutzer im Frontend angefragt haben. Derlei Probleme sind zwar scheinbar immer noch nicht ganz beseitigt, allerdings sammelt sich im Laufe der Jahre doch einiges an URL-Parameter-Spam an, insbesondere wenn Angreifer eine Webseite auf alle nur erdenklichen Sicherheitslücken durchtesten. Teil des Problems ist hierbei, dass derlei Müll-Anfragen von TYPO3 nach Möglichkeit mit einer Seiten-Auslieferung statt mit einem Fehler beantwortet werden.

Wirklich störend wird diese Thematik allerdings, wenn TYPOLinks erzeugt werden und derlei Mülldaten bei der Erzeugung von Links zur HTML-Ausgabe auf einer Webseite mit einfließen: TYPO3 erzeugt dann beispielsweise plötzlich Links, die einen GET-Parameter L=0 beinhalten, angehängt an die von RealUrl erzeugte sprechende URL, also obsolet und unerwünscht. Dieses Verhalten war im Laborversuch festzustellen. Zwar nicht durch URLs von anonymen Dritten, aber durch eigene TypoSkripte. Hier ist es durchaus üblich, einen URL-Parameter L=0 zu setzen, allerdings in der Erwartung, dass die URL dann in die entsprechende Sprache übersetzt wird, und der Parameter L=0 aus der URL entfernt wird. Der Parameter L=0 soll ja gerade bezüglich der Sprache wieder in eine übersetzte sprechende URL übersetzt werden, und dabei natürlich aus der URL verschwinden.

An diesen TYPOLinks hängt jedoch nicht nur die HTML-Ausgabe, sondern auch andere Extensions wie MetaSEO verarbeiten diese URLs ihrerseits wieder, um beispielsweise Sitemaps für Suchmaschinen zu erzeugen. Es zeichnet sich also eine klassische Fehlerfortpflanzung ab, deren Ursache eine Mischung aus RealUrl-Altdaten, RealURL-Bugs in der Vergangenheit und einer suboptimalen RealUrl-Konfiguration irgendwann in der Vergangenheit oder in aktueller Fassung zu sein scheint. Entsprechend mühselig ist die Fehleranalyse.

Natürlich kann man das Problem ein Stück weit (nämlich zur Vermeidung von duplicate content) mit Canonical-URLs abfangen. MetaSEO leistet dies auch unter relativ wiedrigen Bedingungen.

Gute Dienste beim Blockieren unerwünschter zukünftiger Anfragen leistet auch das Apache-Modul defensible, welches mittels DNS-Anfragen prüft, ob eine IP-Adresse in einer Blocklist gelistet ist. Allerdings blockiert dies nur bekannte IP-Adressen und heutige Bot-Netze sind auf IP-Ebene nur noch begrenzt von legitimen Nutzern unterscheidbar.

Den Schönheitsfehler doppelter Einträge in der Sitemap, einmal mit und einmal ohne L=0 Parameter, bekommt man allerdings erst mit einer korrekten Konfiguration von RealUrl und einer grundlegenden Datenbereinigung weg. Eine derartige Datenbereinigung spart auch die manuelle Pflege, die insbesondere bei größeren Seitenzahlen auch an zeitliche Grenzen stoßen würde.

Es bietet sich insbesondere nach einem Update auf eine neue LTS-Version an, eine derartige Bereinigung durchzuführen. Nicht zuletzt möchte man, dass neue Versionen von TYPO3, RealUrl und MetaSEO reibungslos zusammenarbeiten. Hierbei möchte man sicherstellen, dass bezüglich der Altdaten von RealUrl und MetaSEO nicht ein anderes Verhalten entsteht, als bei neu angelegten Seiten. Es sollte schon durchgängig gleich sein, insbesondere will man später im Produktionsbetrieb gefahrlos einen Cache löschen können, ohne dass der Betrieb der Webseite beeinträchtigt wird. Auch bei der zukünftigen Fehlersuche ist es wertvoll, betroffene Software-Versionen eingrenzen zu können.

Im Folgenden nun eine derartige Bereinigung für TYPO3 7.6.18, RealUrl 2.2.0 und MetaSEO 2.0.4.

Vorsichtshalber sollte man die bisherigen Daten sichern:

mysqldump my_typo3_db > /path/to/backup/my_typo3_db.sql
cp typo3conf/realurl_autoconf.php /path/to/backup/

Ggf. wäre auch eine benutzerdefinierte realurl_conf.php zu sichern.

Alte Redirects sind eine recht wertvolle Information, die man nicht so ohne weiteres löschen sollte. Jedoch sollte man ohnehin ein Migrationskonzept diesbezüglich anwenden, da RealURL Redirects nicht mehr wie gehabt umsetzt.

Idealerweise testet man das Folgende auf einem Testsystem, denn im Folgenden kommt es zunächst zu einem (eigentlich gewollten) Datenverlust. Problematisch ist das Folgende insofern, als sich die Daten eigentlich im Anschluss wieder regenerieren sollten. Immanent besteht hierbei die Gefahr, dass dies nicht vollständig oder in ungewollter Weise passiert. Daher sollte man es erst testen.

Zunächst im Extension-Manager in den Einstellungen von RealUrl einstellen, dass RealUrl eine realurl_autoconf.php erzeugen soll.

Anschließend die Extension-Liste im Extension Manager aktualisieren und RealUrl auf die letzte Version aktualisieren.

Die Extension RealUrl dann vorübergehend deaktivieren und die alte typo3conf/realurl_autoconf.php löschen. Danach die Extension RealURL im Extension Manager wieder aktivieren. Ein Schema-Compare bzw. Schema-Update sollte man tunlichst vermeiden. Möchte man die automatische Konfiguration von RealUrl nicht verwenden, dann sollte man zumindest seine bestehende Konfiguration auf einen aktuellen Stand bringen. Alle Altdaten von RealUrl lassen sich löschen mittels:

delete from tx_realurl_pathdata;
delete from tx_realurl_uniqalias;
delete from tx_realurl_uniqalias_cache_map;
delete from tx_realurl_urldata;

Zu beachten ist hierbei, dass im Anschluss nur Einträge neu erzeugt werden, wie RealUrl dazu eben in der Lage ist. Vorherige manuelle Eingriffe usw. gehen durch Löschen der Einträge verloren und sind entsprechend wieder nachzuziehen, sofern sie noch benötigt werden.

Die Sitemap von MetaSEO lässt sich wie folgt leeren:

delete from tx_metaseo_sitemap;

Diese Einträge werden wieder befüllt, sobald die entsprechenden Seiten aufgerufen werden. Die Informationen zu Blacklistings gehen hierbei allerdings verloren und wären manuell nachzuziehen.

Mit Aufruf einer Seite müssten nun die zugehörigen Tabelleneinträge von RealURL wieder erzeugt werden. Analog sollte die Sitemap von MetaSEO wieder befüllt werden.

Bei größeren Seiten bietet es sich an, einen Linkchecker rekursiv über die Seite laufen zu lassen. So ist sichergestellt, dass praktisch jeder Link einmal aufgerufen wird.

Wenn der Linkchecker einmal alle Links aufgerufen hat, kann man überprüfen, ob die von RealURL erzeugten URLs die richtige Form haben. Das geht praktischerweise gleich in der Ausgabe des Linkcheckers, bzw. ansonsten mittels einer Stichprobe von Seitenaufrufen.

Analog kann man die Links in der MetaSEO-Sitemap prüfen. Entweder im Backend-Modul "Sitemap" oder durch Aufruf der Sitemap im "Control Center".

Bezüglich der Sitemap wäre zu prüfen, dass die URLs vom Aufbau her wie gewünscht sind. Außerdem sollte eine Seite im Page-Tree für gewöhnlich pro Sprache auch nur einen Link in der Sitemap erzeugen.

Auch bezüglich der URLs in MetaTags sollte man anhand des erzeugten HTML-Quellcodes Stichproben vornehmen. Insbesondere die Prüfung der URLs in Canonical-Tags wäre aus SEO-Gesichtspunkten wichtig.

Testweise kann man noch ausprobieren, was passiert, wenn man beim Seitenaufruf unbekannte URL-Parameter oder bekannte URL-Parameter wie L=0 an die URL hängt. Idealerweise sind RealURL und MetaSEO nun robust gegen dieses eingangs beschriebene Problem, zumindest war dies im vorliegenden Labortest der Fall.