Schlagwort-Archive: PHP

MAMP aktualisieren

MAMP (My Apache – MySQL – PHP) ist eine lokale Serverumgebung, nicht nur für Apples Mac-Betriebssystem OS X. Zum Aktualisieren dieser Software, bspw. um eine aktuellere PHP-Version zu nutzen, einfach zur Projekt-Website navigieren und dort das entsprechende Paket herunterladen. Zur Überprüfung der Authentizität (aus Sicherheitsgründen) kann die SHA-1-Prüfsumme verglichen werden:

$ openssl sha1 /Users/<USER>/Downloads/MAMP_MAMP_PRO_3.2.1.pkg

Die erhaltene Zeichenfolge sollte mit der auf der Website genannten übereinstimmen.

Anschließend die pkg-Datei ausführen und den Wizard durchlaufen. Eine bestehende MAMP-Installation wird im Laufe der Installation komplett übernommen, d.h. dass alle Projekte (htdocs, db) und Einstellungen in das neue MAMP-Verzeichnis kopiert werden. „Neues Verzeichnis“ deswegen, weil das MAMP-Update eigentlich eine Installation plus die Migration aller enthaltenen Projekte vom bestehenden Server enthält:

  1. Umbenennen des bestehenden MAMP-Verzeichnisses (in der Form MAMP_2015-06-16_08-26-14), sodass eine vollständige Sicherung verbleibt
  2. Installation neue MAMP-Version
  3. Migration (Kopie) des alten htdocs-Verzeichnisses

Das Update ist dann bereits durch. Nun sollte nach Ausführen der Datei /Applications/MAMP/MAMP.app der Webserver starten. Das App-Icon nun noch im Dock belassen, et voila.

Grund für das MAMP-Update bei mir war die Aktualisierung von OS X 10.7 auf 10.10 . Nach dem OS-Update startete Apache nicht mehr (MAMP 3.0.5). Die Versionshistorie von MAMP 3.2.1 deutete bereits auf dieses Verhalten hin: „Problem mit httpd.conf behoben, welches den Start von Apache verhindert hat“.

Anzumerken ist noch, dass die Konfigurations-Dateien des Apache (MAMP/conf/apache/) nicht übernommen werden. Nach Angleich der Dateien, sprich Übernahme der Aliase (Directory-Direktiven) und z.B. Aktivierung der httpd-vhosts.conf ist das alte Verhalten aber wieder hergestellt.

Verschlüsseln und Verschleiern mit PHP & MySQL

PHP und selbst MySQL bieten von sich aus genügend Möglichkeiten, um Passwörter (oder andere Zugangsdaten) zu speichern. Dabei spielt es keine Rolle, ob eine Verschlüsselung (eine Entschlüsselung ist möglich) oder lediglich eine Verschleierung (Bildung eines Hashs) stattfinden soll.

Auf webmasterpro.de oder php-einfach.de sind Beispiele zur Hash-Bildung unter PHP zu finden. Dies ist ein einfacher und zugleich relativ sicherer Weg, um Zugangsdaten per Hash zu speichern.

Per Hash abgelegte Daten können allerdings nicht wiederhergestellt werden. Um Daten zu kodieren und später wieder zu entschlüsseln, sind Verschlüsselungsalgorithmen wie AES oder (der veraltete) DES nötig. MySQL bietet AES bereits von Haus aus an, was das Verschlüsseln eigentlich recht einfach macht. Mit

SELECT AES_ENCRYPT('secret', 'my_salt');

kann bereits eine verschlüsselte Zeichenkette erzeugt werden. Mit

UPDATE table SET value_crypt = AES_ENCRYPT('secret','my_salt');

wird der verschlüsselte String secret in der Datenbank gespeichert, verstärkt durch den Salz my_salt. Dabei spielt es keine Rolle, ob das Passwort-Salz aus einem Datenbank-Datensatz oder per PHP aus einer externen Datei kommt. Wichtig ist aber, dass das Salz möglichst lang ist (bspw. 1024 Zeichen). Auslesen bzw. Entschlüsseln funktioniert mittels der Funktion AES_DECRYPT():

SELECT CAST(AES_DECRYPT(cryptedValue, 'my_salt') AS CHAR) AS decrypted;

Der CAST ist bei Verwendung im PHP-Kontext dringend nötig, wie die Praxis (nicht nur bei mir) zeigt.

Die Techniken lassen sich natürlich beliebig kombinieren. So verwende ich das Hashing per PHP-crypt() bei reinen Zugangskontrollen (Login in Anwendung XY), da dort keine Dechiffrierung nötig ist. Die Verschlüsselung per AES (MySQL) mit per PHP eingebundener Salz-Datei kommt (zusätzlich) in Systemen zum Einsatz, bei denen die Wiederherstellung der (Zugangs-)Daten auf einfache Weise benötigt wird, z.B. einer Passwortverwaltung.

Apache und PHP unter Lubuntu installieren

Apache2 als Webserver und die Skriptsprache PHP5 bilden wohl bei vielen Webworkern den Kern der Arbeit. Somit steht am Anfang die Installation dieser Software-Komponenten.

Die Installation per Terminal gestaltet sich wie folgt:

$ sudo -s
$ apt-get update
$ apt-get install apache2
$ apt-get install php5 libapache2-mod-php5

Um anschließend keine längeren Pfade anzugeben, bietet sich die Einrichtung lokaler Domains an. Dafür gibt es virtuelle Verzeichnisse im Apache. Um beispielsweise die Domain lokal.dev zu erstellen und zu konfigurieren, sind folgende Schritte nötig:

$ nano /etc/apache2/sites-available/lokal.dev.conf
$ a2ensite lokal.dev.conf
$ /etc/init.d/apache2 reload

Die Datei lokal.dev.conf kann als Kopie einer bestehenden Datei erstellt werden. Wichtig sind die Anpassung der Pfade innerhalb des virtualhost-Blocks, damit auch die richtigen Dateien erreicht werden. Mittels a2ensite wird die eben erstellte Konfiguration aktiviert (in /etc/apache2/sites-enabled wird ein Link auf eben diese Datei gesetzt). Anschließend muss die Server-Konfiguration neu eingelesen werden.

Nun muss diese „Domain“ noch auf den lokalen Lookup umgeleitet werden, damit der Browser nicht im weltweiten Netz danach sucht:

$ nano /etc/hosts
dort "127.0.0.1 localhost lokal.dev" ergänzen

Das war’s schon ..

Interessante Links dazu sind:

Formular-Spam ohne Captcha verhindern

Automatisch befüllte Formulare, Inhalte ohne (sinnvollen) Bezug zur Website oder womöglich Herabstufung durch Suchmaschinen sind ein  wahrer Graus.

Das Thema der automatisiert befüllten Formulare fand sich im Gästebuch des Volleyballvereins Grimma eV. Anfangs einmal am Tag (meist gegen 22:00 fünf gleichzeitige Einträge), später in unregelmäßigen Abständen mehrere Einträge täglich. Das genannte Formular sollte allerdings weiterhin ohne Captcha auskommen.

Irgendwo hatte ich gelesen, dass Webcrawler bei solchen Aktionen ALLE Eingabefelder befüllen, wodurch das Erkennen eines automatisierten Befüllens einfach umzusetzen wäre.

Somit zur Umsetzung: Das Formular wird um ein weiteres Input-Element ergänzt, z.B.:

<form action="" method="post>
  <!-- bisherige Eingabefelder -->
  <input type="text" name="myCaptcha" value="" style="display:none;">
</form>

Beim Absenden des Formulars könnte dies nun bereits Clientseitig per Javascript geprüft werden, was bei Webcrawlern allerdings wenig Aussicht auf Erfolg hätte, da JS nicht zur Ausführung käme. Somit muss die Prüfung Serverseitig erfolgen, z.B.:

<?php
# on form submit per POST:
if (!empty($_POST['myCaptcha'])) {
  # prevent positive actions
  $error = true;
  # don't forget input-validation!
  # send email to webmaster here ..
  mail('webmaster@mySi.te','SPAM','possible spam on form: ' . $_POST['myCaptcha']);
  # .. or do whatever you want
}
?>

Es wird lediglich geprüft, ob myCaptcha einen Wert besitzt. Wenn ja, wird im obigen Beispiel eine eMail zur Kenntnisname versendet. Funktioniert recht zuverlässig.