Wie funktionieren Webcrawls bei passwortgeschützten Inhalten, z.B. Medienportalen oder Social Media?
Autor: Antares Reich
Durch aktuelle Umbrüche in der allgemeinen Kommunikation und im Publikationswesen werden Online-Inhalte verstärkt in passwortgeschützte Bereiche von Websites verlagert. Dies betrifft vor allem Social Media und Medienportale, die ihre Inhalte vermehrt kostenpflichtig hinter sogenannten Paywalls anbieten. Webarchive müssen auf diese Veränderungen reagieren, indem sie neue Crawlertechnologien einsetzen.
Dieser Artikel ist die Fortsetzung des letzten Blogbeitrags aus dem Webarchiv: "Browserbasiertes Crawling. Die Evolution des Webs"1, in dem der Browsertrix Crawler und die Browsertrix Profile vorgestellt werden. Ein Browsertrix Profile ist ein Startpunkt für einen Crawl, es speichert Sitzungsinformationen wie Cookies und kann verwendet werden, um eine Website als eingeloggte*r Benutzer*in zu archivieren. Auf vielen Websites wird der Inhalt nur für eingeloggte Benutzer*innen vollständig angezeigt. Daher ist es für ein Webarchiv sehr wichtig, dass man während des Archivierungsprozesses eingeloggt ist, um an den gesamten Inhalt zu gelangen. In einem Webarchiv laufen sehr viele Crawler parallel und deswegen war es erforderlich, das Profil-Handling zu automatisieren.
Das Titelbild zeigt den Ablauf, um die im Browser gespeicherten Nutzer*innen-Daten (Name und Passwort) für einen Login zu verwenden. Voraussetzung dafür ist, dass die Login-Informationen zuvor im Browser gespeichert wurden. Wenn auf einer Website mit hinterlegten Login-Informationen das E-Mail-Feld angeklickt wird, zeigt der Browser ein Drop-Down mit dem, mit einem einzigen Klick, die Login-Informationen in dem Formular eingetragen werden. Genau diese Schritte – von Website aufrufen, das Login Feld anklicken, die gespeicherten Login Daten aufrufen und schließlich den Login Button zu klicken – sollten von einem Programm automatisch durchgeführt werden.
Vor Betrachtung der gesamten Prozesskette ist es wichtig, auch die Einschränkungen und Probleme für eingeloggte Profile zu kennen:
1. Sitzungen/Cookies haben ein Enddatum und werden automatisch beendet, wenn dieses Datum überschritten ist.
2. Websites werden laufend überarbeitet bzw. aktualisiert und Sessions können dadurch ungültig werden.
3. Bot-Detektion-Tools können den Zugriff auf Websites automatisiert beschränken.
Es gibt viele Ansätze, wie die Erstellung von Browsertrix-Profilen automatisiert werden kann, einer wird sogar vom Browsertrix-Crawler selbst geliefert: Die Automatisierte Profilerstellung für die Benutzeranmeldung2.
Aber aus einigen Gründen, z.B. wenn Websites durch Cookie-Consent-Boxen blockiert werden, haben wir uns dazu entschlossen, unser eigenes automatisiertes System zu entwickeln und verwenden dafür die folgenden Technologien:
Um besser verstehen zu können, was die Automatisierung genau bringt, wollen wir die Interaktionen nachvollziehen, die für die Wartung der Browser-Profile bisher notwendig waren. Das Profile-Validierungsprogramm ist schon seit Mitte 2023 im Einsatz und hatte bereits ursprünglich die Aufgabe, zu erkennen, wenn ein Profil invalide wurde und anschließend eine Benachrichtigung per E-Mail zu senden, welches Profil invalide wurde. Dieses Programm startet nun stattdessen ein eigenes Software-Programm (Reinit, siehe unten Automatisierungskette, Schritt 3). Zum neuen Initialisieren des Profils mussten bisher zahlreiche aufwändige manuelle Schritte ausgeführt werden.
Da ein Crawler auf einem Server läuft, hat er in der Regel keine Bildschirme angeschlossen. Das gleiche gilt für andere Ein-/Ausgabegeräte wie Maus oder Tastatur. In der IT wird ein solches Gerät “Headless” genannt. Dies ist normalerweise nicht erwähnenswert, aber in unserem Fall, wenn die menschliche Interaktion mit einer Webapplikation durch ein Programm ersetzt wird, muss diese Interaktion auf dem nicht vorhandenen Bildschirm gelöst werden. Es muss also ein virtueller Bildschirm gestartet werden, bevor die anderen Komponenten so arbeiten können, wie sie sollen. Dazu mussten auf den jeweiligen Websites Bildbereiche, mit denen interagiert werden soll, mit einem Screenshot Tool ausgeschnitten werden, wie zum Beispiel das Login-Feld oder ein Akzeptieren-Button. Diese kleinen Bildausschnitte müssen von Sikuli auf dem virtuellen Monitor gefunden, quasi “gesehen”, werden können.
Erwähnenswert ist, dass auch auf einem virtualisierten Bildschirm die Bildschirmauflösung und die Farbtiefe eine gravierende Rolle spielen und es wichtig ist, die gleiche Farbtiefe auf dem (realen) Bildschirm zu verwenden, auf dem die Bilder vorbereitet werden, wie auf dem virtuellen Bildschirm, auf dem diese Bilder gesucht und angeklickt werden.
Die gesamte Automatisierungskette reicht von der Profilvalidierung bis zur Neuinitialisierung des Profils und wird in der folgenden Abbildung mit allen notwendigen Schritten beschrieben.
Schritt 0: Profil wird invalide
Dieser Schritt ist passiv und passiert nicht zwingend zur Laufzeit eines Crawls; er wird nur durch die Session und Cookie Definitionen der Website, die archiviert werden soll, gesteuert.
Schritt 1: Profilvalidierung
Diese Aufgabe hat nur ein Ziel: zu überprüfen, ob das Profil noch angemeldet ist. Dazu wird eine tiefenlose Archivierung (siehe Crawling – Scope letzter Beitrag, Tiefe 0 in diesem Fall) einer Seite hinter dem Login durchgeführt. Wenn die Seite archiviert wurde, wird der Inhalt des WARC-Files analysiert und wenn der Crawler z.B. zum Login-Formular umgeleitet wurde oder ein bestimmtes Muster wie der spezifische Benutzername oder die E-Mail-Adresse nicht erfasst wurde, wird das Profil als ungültig markiert.
Schritt 2: Vorbereitungen zur Re-Initialisierung
Auf der Crawling-Maschine, die das spezifische Browser-Profil verwendet, wird nun der virtuelle Monitor mit Xfvb und der Browsertrix-Crawler im createProfile-Modus gestartet, der eine mit einem Browser aufrufbare Schnittstelle öffnet.
Schritt 3: Starten des Reinit-Programms
Als nächstes wird das Reinit-Java-Programm gestartet. Es wird etwas verzögert gestartet, um Browsertrix Zeit zu geben, die Verbindung zu öffnen. Das Java-Programm öffnet Chrome mit Selenium (um den Browser durch das Java Programm interaktiv zu machen) und geht an die createProfile Adresse auf dem Localhost.
Schritt 4: Die Magie von Sikuli
Nach der Navigation zu einem Anmeldeformular startet Sikuli und sucht auf dem Bildschirm nach Bildern. Wenn das gesuchte Bild gefunden wird, klickt Sikuli darauf oder interagiert mit dem Formular über die Tastatur. Die Fehlerbedingung ist, dass am Ende des automatischen Anmeldevorgangs ein Verifizierungsbild hinter dem Login gefunden werden muss (meistens das eigene Profil-Bild).
Schritt 5: Prozess Abschluss – neues Profil oder Benachrichtigung
Wenn Sikuli das Verifizierungsbild nicht finden kann, wird das gesamte Java-Programm als fehlgeschlagen zurückgegeben und eine Benachrichtigung gesendet. Falls Sikuli das Verifizierungsbild im Login-Bereich einer Website finden kann, speichert das Programm den Status der Sitzung in einem neuen Browsertrix-Profil und kopiert es nach der Rückkehr des Java-Prozesses an die richtige Stelle, um es beim nächsten geplanten Crawl zu verwenden.
Unser bestehender Workflow wurde auf der IIPC-Web-Archiving-Conference 2024 in Paris im Workshop “Unlocking Access: Navigating Paywalls and Ensuring Quality in Web Crawling” vorgestellt und wird dieses Jahr auch auf dem Videoportal YouTube veröffentlicht.
Die Österreichische Nationalbibliothek bedankt sich sehr herzlich bei der Wiener Städtischen Versicherung für die Unterstützung des Webarchivs Österreich.
Über den Autor: Antares Reich ist Crawl Engineer des Webarchivs Österreich an der Österreichischen Nationalbibliothek.
1 Reich, Antares (2023): "Browser Based Crawling. Die Evolution des Webs", [Online] https://www.onb.ac.at/mehr/blogs/detail/browser-based-crawling-die-evolution-des-webs [15.6.2024]
2 Entwicklungsprojekt Browsertrix Crawler auf GitHub, [Online] https://github.com/webrecorder/browsertrix-crawler [15.6.2024]
3 Selenium automatisiert Browser, [Online] https://www.selenium.dev/ [15.6.2024]
4 Raimund Hocke SikuliX, [Online] https://web.archive.org/web/20240217083947/http://sikulix.com/ [15.6.2024]
Aufgrund von Veranstaltungen wird der Prunksaal am Donnerstag, 24. Oktober bereits um 18 Uhr, am Freitag, 1. November bereits um 16 Uhr und am Donnerstag, 14. November bereits um 18 Uhr geschlossen.
Die Lesesäle am Heldenplatz bleiben am Samstag, den 2. November, geschlossen.