Geben und nehmen

Um Webanwendungen zu steuern, muss wget nicht nur Dateien holen, sondern auch Daten senden sowie Cookies und SSL-Schlüssel beziehungsweise Zertifikate handhaben können. Das alles ist seit der Version 1.10 möglich.

Ruft man wget ohne Optionen auf, also wget , speichert es die vom Server gesendete Seite, etwa index.html, im aktuellen Verzeichnis und gibt das Log des Verbindungsaufbaus auf stderr aus. Umlenken kann man die Seite mit -O und das Log mit -o .

Aber Achtung: Lädt man beispielsweise mehrere Dateien index.html ohne Angabe der Zieldatei herunter, hängt wget ab der zweiten eine zusätzliche Endung . dahinter. Bei Angabe der Zieldatei mit -O überschreibt es bereits existierende Dateien ohne Nachfrage. Dasselbe gilt für die Angabe von Logfiles.

Für den Umgang mit HTTPS-Servern muss wget mit OpenSSL-Unterstützung übersetzt sein. Dann sendet es beim Seitenaufruf einen SSLv2-Gruß und gibt gleichzeitig die SSLv3- und TLSv1-Unterstützung bekannt. Sollte ein Server damit nicht zurechtkommen, kann die genaue Angabe des Protokolls durch - -secure-protocol= das Kommunikationsproblem beheben.

In dem seltenen Fall, dass der Server ein Client-Zertifikat verlangt, hilft die Option - -certificate=. Ist die Datei keine PEM- sondern eine DER- oder ASN1-Datei, benötigt wget noch die Angabe - -certificate-type=.

Häufiger kommt es wohl vor, dass der Client das Server-Zertifikat per Certificate Authorities (CA) überprüfen soll. Befinden sich die benötigten CAs im certs-Verzeichnis der OpenSSL-Installation, etwa /etc/ssl/certs oder /usr/ssl/certs, sollte wget sie dort selbsttätig finden, andernfalls hilft ihm die Option - -ca-directory= auf die Sprünge. Für die Benennung einer bestimmten Datei kennt wget die Option - -ca-certificate=. - -no-check-certificate verbietet wget, das Server-Zertifikat zu überprüfen.

Besonders häufig bei Webanwendungen anzutreffen ist eine Benutzerauthentifizierung. Dafür gibt es zwei Wege: Erstens kann der Webserver die benötigten Daten abfragen, zweitens kann ein HTML-Form die entsprechenden Daten im POST-Format verlangen.

Für die Serverauthentifizierung kennt wget die Optionen - -user= und - -password=. Allerdings hat das denselben Effekt wie die Angabe von Benutzernamen und Passwort in der URL per wget https://login:password@www.beispiel.de - in beiden Fällen sind der Benutzername und das Passwort beim Aufruf von ps sichtbar. Alternativ kann wget den oder die URLs mit der Option -i oder - -input-file= einer Datei entnehmen. Ein wget-Ersatz mit Benutzer-Authentifizierung, der die eigenen Daten aus der Prozessliste fernhält, findet sich in Listing 1.

#!/bin/bash
#Usage: ixwget server wget-Optionen
echo -n "Username: "
read -s username
echo -n "Password: "
read -s password
umask 077
urlfile=~/private/url
echo "https://${username}:${password}@$1" > $urlfile
unset username password
shift
wget -i $urlfile $@
rm -f $urlfile

Fragt der Server die Authentifizierungsdaten als POST-Daten über ein HTML-Formular ab, gibt er im Normalfall ein Cookie zurück, mit dem sich der Benutzer im weiteren Verlauf der Session ausweist. Dazu muss man wget beim Login die Option - -save-cookies auf den Weg geben. Sollten die Cookies abgelaufen sein oder keine Ablaufzeit beinhalten (sogenannte Session-Cookies), muss sich die Anweisung - -keep-session-cookies hinzugesellen. Bei allen weiteren Seitenaufrufen kann sich wget mit - -load-cookies als autorisiert ausweisen.

Für das Einlesen der POST-Daten kennt wget zwei Wege: Entweder mit - -post-data= oder mit - -post-file=. In beiden Fällen müssen die Daten folgendes Format besitzen: name1=value1&name2=value2&name3=value3 - damit lässt sich jedes Eingabe-Element mit name- und value-Attributen füttern. Der String hat allerdings zwei Haken: Erstens muss man das & mit einfachen Hochkommata oder Backslash vor der Interpretationswut der Shell schützen. Zweitens gilt auch hier: Alle Daten im String sind in der Prozessliste sichtbar.

Will man auf eine Webanwendung zugreifen, sollte man vorher mit wget https://www.beispiel.de/login.php -O die Namen und eventuellen Werte der -Tags - vor allem der versteckten - in Erfahrung bringen und mit den benötigten Angaben - ohne Newline-Zeichen - das POST-File füttern. Anmeldung und weiterer Zugriff erfolgen dann mit:

wget --save-cookies <cookiefile> \
  --keep-session-cookies --ca-certificate=<ca-file> \
  --post-file=<post-file> \
   -O <tmp-file> -o <log-file> \
   https://www.beispiel.de/login.php
wget --load-cookies <cookiefile> \  --ca-certificate=<ca-file> -O <tmp-file> \
  -o <log-file> https://www.beispiel.de/app.php

Bei Javascript-Forms, die ausschließlich eine Auswahl durch Mausklick vorsehen, muss wget allerdings kapitulieren. Bietet die Webseite beides, also eine Texteingabe und einen Button zur Auswahl vorgegebener Werte - etwa einen Kalender für die Datumsauswahl -, darf man den Button geflissentlich ignorieren. Allerdings kann es nicht schaden, wenn man sich die Quelltextseite des Kalenders per Browser oder wget holt, um mehr über das geforderte Datumsformat zu erfahren. (sun)