Archive for the ‘PHP’ Category
Punycode, IDN: Welche Probleme es bei Umlaut-Domains in PHP gibt
Naja, eigentlich betrifft es nicht nur Umlaut-Domains hier in Deutschland, sondern allgemein alle Internationalized Domain Names auf der Welt. Also, was passiert wenn wir eine E-Mail an info@müller.de verschicken möchten? Was passiert wenn wir eine an die griechische Domain info@παράδειγμα.δοκιμή verschicken wollten? Was passiert wenn wir auf Port 80 des Webservers von www.müller.de zugreifen wollen? Richtig, alles wird fehlschlagen.
Erstmal zum Grundproblem. Das Internet ist alt, und damals hat noch niemand daran gedacht, dass es auch andere Sprachen als Englisch gibt, deshalb baut alles auf ASCII auf, also mehr oder weniger alles was auf einer englischen Tastatur zu finden ist. Das Domain Name System ist sogar noch strikter und erlaubt nur die 26 lateinischen Buchstaben, die Zahlen 0-9 und den Bindestrich. Das wars!
Man kam also auf die Idee, den Zeichensatz für Domains vergrößern zu wollen. Das interessante daran ist nun aber dass dies geschehen sollte ohne alle Server und Netzwerkgeräte austauschen zu müssen, man benötigte also eine Art Workaround. Deshalb wurde 2003 Punycode eingeführt. Mit Punycode kann man eine Domain, die beispielsweise Umlaute enthält, in eine Domain umwandeln die nur die oben erwähnten 37 zeichen enthält. Aus müller.de wird xn--mller-kva.de . Wie genau diese Umsetzung stattfindet kann im entsprechenden RFC 3492 nachgelesen werden, nur soviel: xn-- deutet auf eine Punycode-Domain hin. Die Umlaute werden angehängt, in diesen angehängten Zeichen ist die Position und der Umlaut codiert.
TLS/SSL für Heimwerker
Gastartikel von Oliver Sperke.
Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.
In den vorhergehenden Beiträgen habe ich ja schon locker über Passwörter und wie man mit Ihnen umgehen sollte erzählt. Dabei wurde auch immer wieder mal angemerkt, dass meistens nicht der Login, sondern die Übertragung dieser Daten das eigentliche Problem wäre. „Man in the middle“, „Sniffer“ und der ganze … Mist. Das beste Mittel gegen viele Sicherheitsprobleme ist sicher SSL oder neu TLS, nur leider ist das für manche Webmaster immer noch nicht einsetzbar. Warum weiß ich persönlich nicht, denn eine zusätzliche IP, die evtl. benötigt wird, liegt bei etwa 1 Euro/Monat und einfache Shared Zertifikate, die meistens vollkommen ausreichen gibt es kostenlos.
Wer aus welchen Gründen auch immer kein TLS einsetzen kann oder will, sollte sich mit anderen Mitteln helfen. Das Ziel muss sein, alle wirklich sensiblen Daten (E-Mail, Passwörter, etc) so zu übertragen, dass sie auf dem Transport nicht gelesen werden können. Das ist schwierig, denn spätestens unser Server sollte es lesen können. Eine Idee ist, die Passwörter mit Einweghashes zu bearbeiten. Da unsere Passwörter aber natürlich sicher verstaut sind, können wir mit dem ankommendem Passwort nichts anfangen. Selbst wenn wir diesen Mechanismus in Javascript komplett nachbauen, wie kriegen wir den geheimen systemweiten Salt rein? Ausserdem gäben wir einem potentiellem „schlimmen Finger“ wichtige Informationen, was im Jahr 2011 keine gute Idee ist. Eine symmetrische Verschlüsselung kommt ebenfalls nicht in Frage, weil wir müssten mindestens einmal den Schlüssel übertragen, was das Verfahren überflüssig macht.
Die einzige sichere Möglichkeit ist das Verfahren, dass auch TLS benutzt. Asymmetrische Verschlüsselung! Da uns per Aufgabenstellung kein TLS zur Verfügung steht, ist unser Ziel, dieses Verfahren möglichst sicher zu kopieren – TLS für Heimwerker. Auch dieses Verfahren ist nicht ganz einfach, denn man muss zusätzliche Software installieren (können). Ich versuche den Aufwand und die Erklärungen aber so einfach wie möglich zu halten. Ein wirklicher Vorteil: Einmal eingerichtet ist es auf unbegrenzt viele Domains auf einem Server anwendbar, völlig unabhängig von der IP. Ein Anwendungszweck, der mir spontan einfällt sind Blog- oder Forenanbieter, wo die Anschaffung von Wildcardzertifikaten zu teuer wäre.
Linkpool Nummer 19
Von guten und schlechten Zufallszahlen.
Performance Probleme beim ternären Operator:
URL Hunter, nettes Spielchen!
PHP Storm 2.1.2 veröffentlicht
RabbitMQ, die Advanced Message Queue:
Screenshots von Webseiten erstellen mit PHP
Einen einfachen manuellen Screenshot von einer Webseite zu erstellen ist einfach, brauche ich hier wohl nicht extra erläutern. Wenn man allerdings aus seiner PHP-Applikation Screenshots von Webseiten erstellen möchte oder keine Lust hat auf manuelles Zusammenkopieren weil die Webseite sehr lang oder breit ist, hilft das Projekt wkhtmltopdf. Dieses Kommandozeilentool gibt es für Windows, Linux und Mac, und es läuft auch auf Servern ohne grafische Oberfläche. Auf der Webseite des Projekts findet man sowohl wkhtmltopdf als auch wkhtmltoimage. wk steht dabei für die Webkit Render Engine, die aus einem gegebenen HTML-Input entweder ein PDF oder ein Bild (jpg, png, tiff) erstellt.
Ich werde hier zeigen wie man Bilder erstellt, die Installation ist einfach: Man lädt sich die passende Version herunter, in meinem Fall für einen Debian-Server ist das wkhtmltoimage-0.10.0_rc2-static-i386.tar.bz2 . Die darin enthaltene Datei kopiere ich nach /usr/local/bin , falls bei euch open_basedir aktiv ist muss es natürlich irgendwo in ein erlaubtes Verzeichnis.
wget http://wkhtmltopdf.googlecode.com/files/wkhtmltoimage-0.10.0_rc2-static-i386.tar.bz2 tar -xjvf wkhtmltoimage-0.10.0_rc2-static-i386.tar.bz2 mv wkhtmltoimage-i386 /usr/local/bin/Ein erster kleiner Test von der Konsole:
wkhtmltoimage-i386 https://www.phpgangsta.de phpgangsta.de.jpgHier das Ergebnis (klicken für das Original Bild):
Mehrere Scripte via Cronjob parallel aufrufen
Heute ein kleines Problemchen mit Cronjobs und Parallelität. Normalerweise empfehle ich Gearman wenn es darum geht, mehrere Scripte im Hintergrund laufen zu lassen, aber nehmen wir an dass wir es mit normalen Cronjobs ohne Gearman lösen wollen.
Wir haben also das Script work.php. Wir möchten alle 5 Minuten die Datenbank prüfen ob es Arbeit gibt, und wenn dem so ist, dann soll die Arbeit erledigt werden. Das geht relativ einfach mit einem Cronjob
*/5 * * * * /usr/bin/php /data/work.php
und in der work.php findet dann die Datenbankabfrage statt. Wenn X Ergebnisse in der Datenbank gefunden werden, wird eine Schleife X mal durchlaufen um alles abzuarbeiten. So weit so gut.
Nun sei die eigentliche Arbeit aber relativ zeitaufwändig, sodass ein Schleifendurchlauf 2 Minuten dauert, und bei 5 Aufträgen dauert es also 10 Minuten (wir arbeiten ja seriell in einer Schleife), der Aufruf von work.php überlappt und wir bekommen ein Problem. Angenommen die Aufgabe ist parallelisierbar, d.h. wenn man alle 5 Aufgaben zeitgleich starten würde gäbe es keine Probleme, und die ganze Arbeit wäre nach 2 Minuten erledigt. Wir könnte man soetwas einfach realisieren?
