„Schlechtes HTML ist teuer (und weitere Weisheiten)“

Eine – wie ich finde – sehr zutreffende Aussage von Jens Meiset ist folgende:

„HTML lernen und schreiben ist nicht schwer, HTML beherrschen aber erfordert tiefgehende Kenntnisse und Erfahrung, um Irrelevantes auszulassen und Wartungsfallen zu umgehen.“
(Quelle: http://www.meiert.com/de/publications/articles/20090211/)

Damit wird wieder einmal bestätigt, dass es eben doch nicht nur darauf ankommt, HTML lesen und schreiben zu können! Echtes Fachwissen wird von den meisten Kunden leider erst erkannt, nachdem sie mindestens einmal schlechte Erfahrung gamacht haben und „auf’s Maul gefallen sind“. Dabei könnte es so einfach sein …

Subversion (SVN) Hooks

So genannte Hooks können über „Event-Einstiegspunkte“ im SVN Server eingehängt werden. Diese werden entsprechend dem Event ausgeführt (z. B. pre-commit, also vor einem Commit) und können z. B. Dateiprüfungen vornehmen. Hooks werden immer je Repository eingerichtet.

Dieses Beispielhafte pre-commit prüft, ob eine Datei die Eigenschaft „svn:keywords=Id“ gesetzt hat und bricht den Commit ggf. mit einer Fehlermeldung ab.

Hooks werden einfach als Datei mit dem Namen des Events (z. B. „pre-commit“) im Verzeichnis „hooks“ des jeweiligen Repositories abgelegt.

Neue Dateien vor dem Hinzufügen automatisch mit Eigenschaften versehen

Über die Konfiguration des SVN Clients (Windows: C:\Dokumente und Einstellungen\[User]\Anwendungsdaten\Subversion\config, Linux: /home/[User]/.subversion/config o. ä.) folgende Einstellungen aktivieren:


[miscellany]
enable-auto-props = yes
[auto-props]
*.php = svn:keywords=Id LastChangedRevision
*.php4 = svn:keywords=Id LastChangedRevision

Dann wird allen neu hinzugefügten *.php und *.php4 Dateien automatisch die Eigenschaft „svn:keywords=Id LastChangedRevision“ hinzugefügt. Für bereits im SVN bestehende Dateien muss diese Eigenschaft maneuell gesetzt werden.

Zugriff auf eigene Bilder von fremder Domain sperren

Bilderklau ist im Internet leider allzu verbreitet! Wenn aber nicht einmal eine Kopie von dem Bild gemacht wird, sondern das Originalbild direkt im fremden Quelltext eingebunden wird, hat der Seitenbetreiber des Originalbildes nicht nur unnötig höheren Traffik, sondern auch noch eine höhere Serverlast zu bemängeln.

Um diese Art des Bilderklaus zu unterbinden, kann eine kleine RewriteRule z.B. in einer .htaccess Datei eingesetzt werden:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Was passiet hier nun?

Wenn der Referer leer ist, oder nicht die eigene Domain ist, dann wird der Zugriff auf alle Dateien mit der Endung .gif, .jpeg, .jpg oder .png verboten. Wenn leere Referer zugelassen werden sollen, einfach die erste Zeile mit RewriteCond entfernen (nicht jeder Browser sendet den Referer (korrekt) mit).

Weitere Domains zulassen

Um weiteren Domains den Zugriff auf die Dateien zu erlauben, muss diese einfach in einer RewriteCond hinzugefügt werden.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?andere-eigene-domain.tld(/)?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?erlaubte-fremde-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ [F,NC]

Andere Anwendungen/Dateiendungen

Die Liste der zu sperrenden Dateien, bzw. Dateiendungen kann einfach ergänzt werden (letzte Zeile, RewriteRule), so lassen sich dann z. B. auch PDF/DOC/etc. Dateien sperren.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png|pdf|doc)$ [F,NC]

Nicht sperren, sondern alternativen Inhalt zeigen

Statt den Zugriff zu sperren, kann man auch einen alternativen Inhalt/alternative Datei ausliefern. Dies könnte z.B. ein anderes Bild/Dokument sein, in dem auf den Datenklau hingewiesen wird. Diese Methode spart zwar keinen Traffik oder Serverlast, kann aber auch wirksam sein ;)

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?eigene-domain.tld(/)?.*$ [NC]
RewriteRule .*\.(gif|jpe?g|png)$ /do-not-steal.gif [NC]

neues Zend Framework Rewrite

Seit einiger Zeit findet sich im Quickstart Tutorial (englisch) des Zend Frameworks eine neue verbesserte RewriteRule:

Wird das mod_rewrite Modul unter Apache verwendet, wird empfohlen, eine .htaccess Datei mit folgendem Inhalt im Hauptverzeichnis der Domain (DocumentRoot) abzulegen:

# public/.htaccess
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]

Was passiert hier nun?

Die Umgebungsvariable REQUEST_FILENAME beinhaltet laut Apache-Dokumentation den vollen Pfad zur Datei oder zum Script entsprechend der Anfrage (z.B. /var/www/domain.tld/public/css/style.css).

Die drei Bedingungen (RewriteCond) prüfen nun, ob diese/s Datei/Script eine tatsächlich existierende Datei (s), symbolischer Link (l) oder ein Verzeichnis (d) sind. Wenn ja: leite die Anfrage unverändert durch und beachte keine weiteren Regeln ([L] = Last/Letzte Regel), also kein Rewrite und Ende der Prüfung. Wenn nein: Schreibe die Anfrage zu /index.php um. Das NC bewirkt, dass nicht zwischen Klein- und Großschreibung unterschieden wird (NC = no case-sensitive).

Besonderheit bei Deklaration der Rewrite Bedingungen/Regeln innerhalb eines VirtualHost
Die zuvor aufgezeigten Bedingungen gelten für die Deklaration innerhalb einer .htaccess Datei. Gleichermaßen kann das Rewriting natürlich auch innerhalb einer VirtualHost Definition deklariert werden.

Jedoch ist bei einer Deklaration innerhalb eines VirtualHosts zu beachten, dass die Umgebungsvariable REQUEST_FILENAME hier nicht den vollen, sondern den relativen Pfad vom DomainRoot beinhaltet.

In den Bedingungen muss daher die Umgebungsvariable DOCUMENT_ROOT zusätzlich vorangestellt werden!
Der Rest bleibt erhalten.

# innerhalb VirtualHost Deklaration
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -s [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -l [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ /index.php [NC,L]