Blogix

Gestern brauchte ich schnell eine PHP-Funktion um Zufallspasswörter zu erzeugen. Auf TotalyPHP wurde ich auch fündig. Ich habe die Funktion dann noch ein wenig optimiert. Hier meine Version:

Source code

<?php
function createRandomPassword( $laenge ) {
 
	// $chars enthaelt alle Zeichen, die zur Erzeugung des Passworts benutzt werden. Kann beliebig angepasst werden.
	// In meinem Beispiel sind nur Kleinbuchstaben und Zahlen drin. Leicht zu verwechselnde Buchstaben habe ich entfernt.
	$chars = "abcdefghkmnpqrstuvwxyz23456789";
	srand((double)microtime()*1000000);
 
	$pass = '' ;
 
	for ($i=0; $i <= $laenge; $i++) {
		$pass .= substr($chars,  rand(0,strlen($chars)),  1);
	}
	return $pass;
}
 
?>

Bildbearbeitungen unter PHP sind mit der bekannten GD-Lib schon lange möglich. Auch die Bibliothek ImageMagick ist eigentlich ein alter Zopf. Trotzdem war es (für mich) nicht ganz einfach auf meiner lokalen XAMPP-Entwicklungsumgebung unter Windows Vista diese schöne PHP-Extension zum Laufen zu bringen.

Wenn man so was nicht regelmäßig macht, dann steht meiner einer erst mal vor einigen Fragezeichen. Welche Version von welchen DLLs gehören wo hin? Wie aktiviere ich das in meiner PHP-Version? Welche PHP-Version muss es sein?

Folgendes Vorgehen führte bei mir letztlich zum Ziel:

1. Frische XAMPP-Version (1.7.4) installieren. Wichtig war hier, dass mindestens PHP Version 5.3.x oder besser enthalten ist. Unter Windows Vista ist noch wichtig, XAMPP nicht in den üblichen Programme-Ordner (z.B. C:\Program Files) zu installieren. Das kann zu Problemen mit der Vista Rechtesteuerung führen. Ein gute Alternative ist C:\xampp.
   (Man kann übrigens auch mehrere XAMPP-Installationen parallel auf dem Rechner haben solange man die Komponenten (Apache, MySQL-Server etc.) nicht als Dienste betreibt).
2. Die eigentliche XAMPP-Bibliothek als DLL-Datei für Windows (Binary Release) von http://www.imagemagick.org/script/binary-releases.php#windows herunterladen. WICHTIG: die “dynamic at 16 bits-per-pixel”-Version nehmen. Ob Win32 oder Win64 hängt dann von der Windows-Version ab.
   Auch hier sollte man die Installation NICHT in das vom Installer vorgeschlagene Windows-Programme-Standardverzeichnis vornehmen. C:\ImageMagick ist prima
   Beim Installieren die Option zum Anlegen der Pfade unbedingt aktiv lassen – sonst kann die PHP-Extension später nix finden. Windows sollte man nach der Installation einmal neu starten.
3. Jetzt braucht man noch die richtige DLL-Datei, die die imagick-PHP-Extension enthält. Denn nur diese kann mit der ImageMagick-DLL sprechen. Auch hier ist man als “Laie” zunächst überfordert. Gibt es doch von offizieller Seite leider kein konkretes vorgehen für Windows.
   Man muss sich Quellen wie dieser bedienen: http://www.sk89q.com/2010/03/vc6-windows-binaries-for-imagick-2-3-0/. Hier findet sich eine passende DLL, die in das Verzeichnis \ext\ der PHP-Installation (die bei XAMPP wiederum in \php\ zu finden ist) legen. Bei mir war das dann der Pfad C:\xampp2\php\ext\.
   Hinweis: Die meisten Quellen verweisen auf die Kompilate von valokuva.org. Diese DLLs sind aber nicht kompatibel zu der XAMPP-PHP-Kompilierung für Windows. Beim Start von XAMPP kommt dann die nebenstehende Fehlermeldung. Offensichtlich ist VC6 was anderes als VC9. Mehr habe ich auch nicht verstanden
4. Als letzten Schritt muss man noch die neue PHP-Extension in der php.ini aktiviert werden. Die php.ini liegt im \php\-Ordner von XAMPP und sollte natürlich nur mit einem Texteditor wie Notepad++ bearbeitet werden.
   Jetzt gibt es zwei Möglichkeiten. Entweder die Extension ist schon als Zeile vorhanden, aber auskommentiert oder sie fehlt komplett. Einfach mal nach “php_imagick” suchen. Findet sich eine Zeile der Art
   ;extension=php_imagick.dll
   dann muss nur das Semikolon am Zeilenanfang entfernt werden um die Extension zu aktivieren. Fehlt diese Zeile komplett, dann muss diese (ohne Semikolon) ergänzt werden (am besten unter dem Block wo sich auch schon die ganzen anderen extension=… Eintragungen befinden.
5. Als letztes XAMPP starten und testen. Hier noch ein kleines Testscript, dass als Ausgabe ein kleines Bild generiert:

   <?php

    /* How wide is our image */

    $image_width = 200;

    /* Give zero for autocalculating the height */

    $image_height = 200;

    /* Specify the text */

    $text = "Lorem ipsum dolor sit amet, consectetuer adipiscing elit.

    Mauris lectus mi, mattis non, euismod vel, sagittis nec, ipsum.";

    /* Instanciate imagick */

    $im = new Imagick();

    /* Create new image using caption: pseudo format */

    $im->newPseudoImage( $image_width, $image_height, "caption:" . $text );

    /* Put 1px border around the image */

    $im->borderImage( 'black', 1, 1 );

    /* PNG format */

    $im->setImageFormat( "png") ;

    /* Output */

    header( "Content-Type: image/png" );

    echo $im;

    ?>

PHP-Caches sind nicht immer nur für massive Performance-Gewinne, sondern manchmal auch für unerklärliche Fehler verantwortlich. So vertragen sich z.B. Horde und eAccelerator nicht. Die generierte Fehlermeldung lässt andere Fehlerquellen vermuten, an eAccelerator denkt man dabei aber vorerst nicht:

Warning: IMAP_Tree::require_once() [function.IMAP-Tree-require-once]: open_basedir restriction in effect. File(Horde/SessionObjects.php) is not within the allowed path(s): (/usr/share/php:/usr/share/pear:/usr/share/horde3:/etc/horde:/usr/lib:/usr/sbin:/var/log) in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Fatal error: Can’t load Horde/SessionObjects.php, open_basedir restriction. in /usr/share/horde3/lib/Horde/IMAP/Tree.php on line 311

Man erhält also eine “open_basedir restriction”-Fehlermeldung, wie man sie schon häufig gesehen hat. Erste Vermutung ist natürlich, dass die in der php.ini konfigurierten Pfade für open_basedir nicht korrekt sind. Also sucht man zuerst nach der Datei “Horde/SessionObjects.php” und erkennt, dass sich diese an “/usr/share/horde3/lib/Horde/SessionObjects.php” befindet – dieser Pfad ist lt. open_basedir-Einstellung “…:/usr/share/horde3:…” aber eindeutig erlaubt. Die Suche geht weiter und weiter und… bis man auf die Idee kommt, dass man vor ein paar Tagen einen PHP-Cache installiert hat. Sofort nach der Deaktivierung desselbigen funktioniert wieder alles problemlos. Wie meine weiteren Recherchen herausgestellt haben, tritt dieses Problem nicht nur mit eAccelerator auf, sondern auch mit APC, usw.

Wichtige Daten (z.B. Benutzername und Passwort, Daten der Bankverbindung,…) sollten immer über eine gesicherte SSL-Verbindung übertragen werden. Um eine verschlüsselte Verbindung zu erhalten, können mehrere Wege eingeschlagen werden. Ich möchte hier den Weg per PHP und den per .htaccess aufzeigen. Diese beiden Beispiele funktionieren im Gegensatz zu vielen anderen im Internet auch mit anderen als dem Standard-Port 993 für SSL.

SSL-Verschlüsselung mit PHP erzwingen

if (!isset($_SERVER['HTTPS']))
{
	header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . $_SERVER['QUERY_STRING']);
}

Wenn ein anderer Port als der Standard-Port verwendet wird, muss dieser noch eingefügt werden – z.B. “$_SERVER['HTTP_HOST'] . ‘:123′ . $_SERVER['REQUEST_URI']“, wobei “123″ mit dem gewünschten Port ersetzt werden muss.

SSL-Verschlüsselung mit .htaccess erzwingen

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Auch hier muss noch der Port eingefügt werden, sollte dieser nicht Standard sein – z.B. “https://%{HTTP_HOST}:123%{REQUEST_URI}”, wobei auch hier “123″ mit dem gewünschten Port ersetzt werden muss.

Auf Shared Hosting-Umgebungen (mehrere Benutzer teilen einen Webserver) ohne suphp oder PHP im CGI-Mode kommt es zu dem Problem, dass der Apache-Webserver und PHP für alle Domains mit einem Benutzer (z.B. “www-data”) ausgeführt werden. Das hat zur Folge, dass von PHP erstellte Dateien dem Apache-Benutzer gehören und meist auch nur der Besitzer (Apache-Benutzer) schreibend darauf zugreifen darf. Shared Hosting-Kunden melden sich aber mit FTP-Accounts an, die ungleich dem des Apache-Benutzers sind. Das führt dazu, dass FTP-Benutzer die vom Apache-Benutzer angelegten Dateien überlicherweise nicht löschen dürfen.

Um die Dateien wieder ändern oder löschen zu können, hat man zwei Möglichkeiten:

1. Beim Erstellen führt man direkt ein chmod() oder chown() aus und gewährt dem eigenen FTP-Benutzer die notwendigen Berechtigungen.
2. Man schreibt ein Skript, das diese Aufgabe hinterher ausführt und ruft dieses mit einem Browser auf.

Ein derartiges Skript könnte wie folgt aussehen (in diesem Beispiel werden alle Dateien und Ordner aus dem Ordner “fileadmin” gelöscht, der sich auf der selben Ebene wie das Skript befindet):

function recursive_readdir($path)
{
	$handle = opendir($path);
	while (($file = readdir($handle)) !== false)
	{
		if ($file != '.' && $file != '..')
		{
			$filepath = $path . '/' . $file;
			echo $filepath.'<br />';
			if (is_dir($filepath))
			{
				rmdir($filepath);
				recursive_readdir($filepath);
			}
			else
			{
				unlink($filepath);
			}
		}
	}
	closedir($handle);
}

recursive_readdir('./fileadmin');