Grundbegriffe:

• Client (normalerweise ein Browser)
• Server (normalerweise ein Webserver einer Webseite)
• URL
• Request (vom Client ausgelöst), Response (vom Server als Anfrage auf einen Request)
• Header (Meta-Informationen zum Request oder zur Response)
• Content (Eigentlicher Inhalt des Requests (kann leer sein) oder der Response)
• Statuscodes Doc Fun
• Cookies sind Key/Value-Pairs, können in der Response auf dem Client gesetzt werden, werden in jedem Request geliefert.

• Besuchen Sie die «sehr einfache Webseite» https://blog.fefe.de/
• Öffnen Sie die Entwicklertools (F12)
• Öffnen Sie den Tab «Network» und studieren Sie dort die Headers (auch raw!)

• Im gleichen Tab, mit den Entwicklertools offen, besuchen Sie https://ksbg.nesa-sg.ch/
• Studieren Sie die Request- und Response-Headers, insbesondere die Cookies.
• Loggen Sie sich mit falschem Passwort ein (z.B. XXXXXXXXXXX, das sieht man gut).
• Studieren Sie dann den Request, insbesondere den Inhalt.

Curl ist ein extrem mächtiges Kommandozeilentool, um diverse Web-Zugriffe (und andere Protokolle) auszuführen.

Firefox und Chrome erlauben es, einen Request direkt als curl-Kommandozeile zu kopieren und ihn so zu reproduzieren.

Damit das mit Nesa funktioniert, müssen jeweils auch die Cookies (und evtl. weitere Dinge) mitgsendet und angepasst werden. Dazu werden die folgenden Optionen zusätzlich verwendet:

curl -L -b nesa-cookies.txt -c nesa-cookies.txt ....

Damit werden Redirects verfolgt (-L) und die cookies aus einer Datei gesendet (-b) und gespeichert (-c).

Wir könnten mit regular Expressions dahinter, das ist aber mühsam und unstabil.

Wir verwenden deshalb eine Bibliothek, die HTML parsen kann und womit der entstehende Baum mit XPath durchsucht werden kann.

• lxml Library for Python
• XPath

Um sich nicht die ganze Zeit in NESA neu anzumelden, speichern Sie jeweils die aktuelle Seite in Datei und laden Sie diese direkt ins Programm. Um eine Seite weiterzukommen, müssen die Seiten aber vom Web geladen werden.

Im folgenden werden die verwendeten Techniken vorgestellt, wie überhaupt entdeckt wurde, dass und dann wie die Raumpläne in XML geladen werden.

Start: Auf der Raumplanseite, wo Räume ausgewählt werden können. Developper-Tools, offen.

• Feststellung, dass die Seite bei der Auswahl nicht komplett neu geladen wird, sondern nur der Plan ersetzt wird.
  • Das ist ein Hinweis darauf, dass die Daten dynamisch via JavaScript geladen werden.
• In den Entwicklertools können die Netzwerkzugriffe protokolliert werden. Dort ist die obige Feststellung überprüfbar.
• Der interessante Zugriff ist jener auf scheduler_processor.php, der etwas vom Typ xhr liefert und von einer Datei ajax.js ausgelöst wurde.
  • AJAX = Asynchronous JavaScript And XML. Wird benutzt, um Daten nachzuladen (oder auch um auf den Server zu übertragen), ohne die Seite neu laden zu müssen.
  • Der Inhalt ist tatsächlich XML (könnte auch für JSON verwendet werden). Genau das was wir brauchen.
    • Hinweis: Heute sollte die Fetch-API anstelle von XMLHttpRequest verwendet werden.
• Nächstes Problem: Wo wird die URL erzeugt?
• Breakpoint vor dem Zugriff setzen, Stacktrace analysieren (d.h. die Kette der aufrufenden Funktionen).
  • Die interessante Funktion ist hier loadStundenplanReal, die direkt im index.php ausgeliefert wird (Zeile 2994, eventuell nicht stabil).
• In Zeile 3014 ist auch die korrekte URL kodiert, wobei einige Parameter gewählt werden müssen.

Damit hat man alles Nötige, um die XML-Daten via curl zu laden. Man könnte jetzt noch reiner Neugierde schauen, ob man den Code findet, der den Stundenplan darstellt.

• Z.B. Zeile 1873 hat auch sonst noch spannende Infos (Zimmer und Lehrerliste).