PHP hat einen “goes to”-Operator. Die Integer-Variable $x geht dabei schrittweise Richtung Null. Beispiel:

<?php
$x = 10;
while ( $x --> 0 ) {
    echo $x . ' ';
}
?>

Ausgabe:

9 8 7 6 5 4 3 2 1 0

Sensationell. Im PHP-Manual wird dieser Operator nicht erwähnt. Warum? Weil es in Wirklichkeit zwei Operatoren sind. Geparst wird das ganze nämlich so:

<?php
$x = 10;
while ( $x-- > 0 ) {
    echo $x . ' ';
}?>

Und jetzt ist die Bedingung in der While-Schleife ein ganz normaler Post-Dekrement gefolgt von einem Vergleich. Das Ganze funktioniert also nur in die absteigende Richtung. Für die andere Richtung müsste man ++< schreiben – sieht dann aber nicht mehr so schick aus.

Anbieter für Wegwerf-E-Mail-Adressen gibt es viele. Ich persönlich bin Mailinator-Nutzer der ersten Stunde. Mailinator war immer zuverlässig und tut genau das was es soll: temporäre E-Mail-Postfächer bereitstellen.

Mailinator gehört zu den größten/bekanntesten Anbietern – und genau das ist auch das Problem. Viele Seiten, die eine Anmeldung mit gültiger E-Mail-Adresse fordern, blockieren die bekannten Wegwerf-E-Mail-Anbieter.

Aber es gibt Abhilfe. Statt @mailinator.com kann man auch jede andere Domain nehmen, deren MX-DNS-Eintrag auf den selben Mailserver zeigt, wie der von @mailinator.com. Doch wie ist die IP-Adresse des Mailinator-Mailservers?

$ dig MX mailinator.com
; <<>> DiG 9.5.1-P3 <<>> MX mailinator.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54319
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mailinator.com.                        IN      MX

Wie wir sehen, sehen wir nichts. Hat eine Domain keinen MX-Record, so wird automatisch der A-Record als Mailserver angenommen:

$ dig A mailinator.com
; <<>> DiG 9.5.1-P3 <<>> A mailinator.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7356
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mailinator.com.                        IN      A
;; ANSWER SECTION:
mailinator.com.         77483   IN      A       66.135.60.177

Blöd nur, wenn man mal eben keine Domain (Subdomain reicht auch) zur Hand hat, deren MX-Eintrag man auf die Mailinator-IP ändern kann. Zum Glück kann man bei DynDNS auch freie MX-Records vergeben:

Isi manni! Bei “MX-Hostname” entweder mailinator.com, mail.mailinator.com (das war früher mal der MX von mailinator.com) oder direkt die IP (66.135.60.177) eintragen.

Statt irgendwas@mailinator.com kann man jetzt einfach irgendwas@dyndnsacc.kicks-ass.org verwenden. Somit umgeht man die Sperre zu 99%. Die Mails landen trotzdem direkt in der Mailinator-Inbox. Man könnte natürlich direkt den MX-Record prüfen und sperren, ist mir aber bisher auf noch keine Seite passiert. Let them eat spam!

AWStats analysiert Logfiles und erstellt nette Statistiken. So auch hier für diesen Blog. Um die schier unfassbare Menge an Visits auch nur im Ansatz zu begreifen, rödelt also jede Nacht AWStats durch die Apache-Logfiles. Das hat im Gegensatz zu Google-Analythics den Vorteil, dass die Daten schön hier lokal gespeichert werden. Außerdem erfolgt die Erfassung der Daten Serverseitig und nicht per Javascript. Das wird nämlich von vielen Usern einfach geblockt (Hallo <noscript>!).

Statistiken sind nie zu 100% genau. Dennoch stört mich, dass die eigenen Hits in den Statistiken auftauchen. Das lässt sich aber verhindern..

Methode 1: eigener vHost

Einfach einen zweiten VHost, z.b. dev.domain.com anlegen. Der VHost zeigt ins selbe Verzeichnis wie die Hauptdomain, hat aber eine extra Logdatei. AWStats wertet nur die Logs der Hauptdomain aus. Die Links auf der Webseite müssen dazu aber zwingend relativ sein – sonst landet man früher oder später wieder auf der Hauptdomain und wird “erfasst”.

Bei WordPress stellte sich das schon mal als sehr schwierig heraus. Viele Links enthalten hier direkt den Domainnamen.

Methode 2: Apache conditional logging

Per conditional logging werden bestimmte Logeinträge erst gar nicht geschrieben. Als Kriterium kann z.B. die IP-Adresse verwendet werden. Mit DSL und daher dynamischer IP aber eher schwierig. Bleibt also nur noch der Cookie zur Identifikation. Wir setzen auf der eigenen Seite einen bestimmten Cookie, z.B. “DONTSTATME=true”. Dazu einfach in die Adressleiste des Browsers folgendes tippen:

javascript:document.cookie="DONTSTATME=true; expires=Sat, 17 Dec 2011 22:59:00 GMT"

Nach reload der Seite ist der Cookie gesetzt. Jetzt können wir das conditional logging konfigurieren:

SetEnvIf HTTP_COOKIE "(^| )DONTSTATSME=true($|;)" dontlog
CustomLog logs/access_log common env=!dontlog

Nachteil hier: Requests mit diesem Cookie werden jetzt gar nicht mehr geloggt. Nirgends. Generell eine schlechte Idee. Irgendwie. Außerdem legt Syscp pro VHost automatisch einen CustomLog-Eintrag an, der sich leider nicht so leicht um “env=!dontlog” erweitern lässt. Zumindest nicht ohne an der Source rumzufummeln.

Methode 3: Logfile greppen

AWStats akzeptiert auch Logfiles von einer Pipe: mit grep -v DONTSTATME=true /path/to/log würden bei AWStats nur “richtige” Hits ankommen. Dazu muss man den LogFile-Parameter der AWStats-Config folgendermaßen anpassen (/etc/awstats/awstats.domain.com.conf):

LogFile="grep -v DONTSTATME=true /path/to/access.log |"

Problem: Das Apache “combined”-Logformat loggt gar keine Cookies. Lässt sich aber leicht ändern. Wir öffnen die Datei /etc/apache2/apache2.conf und suchen die Zeilen mit “LogFormat”.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\"" combined

Entweder die Zeile mit “combined” direkt abändern oder ein neues Logformat erstellen, z.B. combined-cookies.

Dann muss AWStats das neue Logformat noch mitgeteilt werden (/etc/awstats/awstats.domain.com.conf):

LogFormat = "%host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot %otherquot"

Apache restart/force-reload und alles ist gut. Vorausgesetzt man vergisst nicht den Cookie zu setzten, wenn man Methode 2 oder 3 verwendet.

Wie jetzt?

Jede Methode hat Ihre Vor- und Nachteile. Keine ist Perfekt. Ich bin noch am evaluieren :D Im Endeffekt müssen einfach nur insgesamt genug Hits vorhanden sein. Dann spielen die paar eigenen Visits auch keine Rolle mehr und man muss sich um das ganze Zeug keine Gedanken mehr machen. Solange das nicht der Fall ist, macht es durchaus Sinn, sich die Mühe zu machen und die eigenen Besuche auszuschließen.

Beim Cineplex Neckarsulm kann man unter http://212.20.182.131/ online Karten (Sitzplätze) reservieren. Nach kostenloser Registrierung kann man ebenfalls kostenlos bis zu vier Sitzplätze reservieren. Das ist natürlich viel zu wenig. Glücklicherweise nimmt es das System mit der Überprüfung der Formulardaten nicht so genau. Stichwort: Input Validation. Das ist die Überprüfung aller Nutzer-Daten auf Plausibilität hin: Ist die E-Mail-Adresse korrekt, ist die Postleitzahl 5-stellig oder in diesem Fall: liegt die Anzahl der zu reservierenden Sitze zwischen 1 und 4 ?

Formulare lassen sich auf Clientseite leicht manipulieren. Firebug bietet sich hier geradezu an. Firebug ist ein Firefox-Plugin, mit dem man unter anderem das DOM der Webseite einsehen und bearbeiten kann. Um die Anzahl der zu reservierenden Sitze leicht zu erhöhen, einfach mit dem Inspector auf das SELECT-Element klicken, und einen der Option-Werte anpassen. Opera kann das übrigens von  Hause aus: Darstellung -> Quelltext, <option> manipulieren, klick oben auf “Änderungen anwenden”.

Normalerweise sollten die Daten nach dem Absenden des manipulierten Formulars auf der Serverseite überprüft werden. Das ist hier aber offenbar nicht der Fall.

Schon besser.

Das Beispiel zeigt, dass eine Webanwendung grundsätzlich jedem User-Input misstrauen sollte und diese Daten niemals ungeprüft übernehmen sollte. Das betrifft nicht nur Formular-Daten sondern auch Cookie-Daten, GET/POST und sonstige, vom Nutzer übermittelte Daten. Aber wer wird es dem armen ASP-Frickler Entwickler schon verübeln ..

Domains gibt es überall. Meist direkt vom Server-Anbieter. Diese sind aber oft teurer als nötig und zudem ziemlich unflexibel zu verwalten. Wenn man mit dem Server zu einem anderen Anbieter umzieht, muss man alle Domains mitnehmen.

Das geht auch einfacher und billiger: mit einem Domainrobot. Voraussetzung hierfür ist zwingend ein Server mit Root-Rechten oder ein Provider, der externe Domains erlaubt.

Den ganzen Beitrag lesen…