Sprechende URLs mit GetSimple CMS und nginx

Ich liebe so kleine CMSe wie GetSimple, mit denen man ohne Datenbank-Gedönse schnell eine kleine performante Website hochziehen kann. Auf einem Raspberry Pi 2B habe ich einen Webserver mit nginx aufgesetzt, die Dateien von GetSimple CMS eingespielt – und läuft. Nun kann nginx leider nicht mit den .htaccess-Dateien von Apache umgehen, mit denen man z. B. Zugriffsbeschränkungen und Redirects steuern kann. Das führt bei GetSimple dazu, dass man im Backend unter den Einstellungen den Haken bei „Nutze freundliche URLs – Erfordert mod_rewrite auf Ihrem Server“ zwar setzen kann, wenn man dann aber auf der Website in der Navigation auf entsprechende Unterseiten klickt, rennt man gnadenlos auf einen Server-Error 500.

Hier muss man also statt .htaccess direkt in der Serverkonfiguration editieren. Unter /var/www/etc/nginx/sites-available öffnet man mit su-Rechten die Datei „default“. In dem Bereich „server { … }“ sucht man sich den Eintrag „location / { … }“ und fügt dort folgende Zeile ein:

try_files $uri $uri/ /index.php?id=$uri&$args;

Dieser Eintrag sorgt dafür, dass GetSimple URLs umschreiben kann. Jetzt diese Datei speichern und mit „sudo service nginx restart“ den Webserver neu starten. Und nun klappt es auch mit den Fancy URLs. Das wird übrigens auch die SEO-Freaks freuen.

Wer sich in die GetSimple-optimierte nginx-Konfiguration einarbeiten möchte: Hier findet man eine gute Dateivorlage mit den Zugriffsrechten innerhalb der GetSimple-CMS-Verzeichnisstruktur.

 

Eigene Webseiten vor fremden Frames schützen

Es kommt ja immer wieder mal vor, dass die eigene Homepage irgendwo im Web von fremden Leuten per HTML-Frame eingebunden wird – diese Leute machen sich also fremde Webseiten zu eigen. Okay – das mag allenfalls ein urheberrechtliches Problem sein, aber man kann diese uralte HTML-Technik (Frames sind in HTML5 nicht mehr vorgesehen!) auch für richtig bösartige Sachen nutzen. Da baut sich jemand Böses einen Frameset, bindet darin meine Webseite ein und verlinkt seinen Frameset z. B. bei Twitter. Nun wird meine Webseite von zigtausenden Surfern angeklickt – schlimmstenfalls reißt das meinen Webserver in die Knie. Oder jemand lässt mittels Frames meine schöne, hochkulturell wertvolle Seite zusammen mit was-weiß-ich-was-für Seiten im Browser erscheinen.

Wie kann man das nun verhindern? Nun, ich betreibe eine kleine Homepage auf einem Apache2-Server auf einem Raspberry Pi (für wenige Besucher pro Stunde reicht das voll und ganz). In der httpd.conf habe ich eine Zeile eingefügt, welche bewirkt, dass in dem HTTP-Response-Header eine Anweisung ausgegeben wird, dass meine Webseiten nur von meinem eigenen Webserver in Frames eingebunden werden darf. Diese Zeile lautet wie folgt:

Header always append X-Frame-Options SAMEORIGIN

Anstatt „SAMEORIGIN“ kann man auch die Option „DENY“ setzen. Dann darf nicht mal mehr mein eigener Webserver den Content in Frames darstellen – wer weiß, was meine Designer-Kollegen da für einen Unfug treiben 🙂

Nachdem man die Änderung in der httpd.conf gespeichert hat, startet man den Webserver mit sudo service apache2 restart neu. Sollte es beim Neustart zu Fehlermeldungen kommen, ist in der Apache2-Konfiguration das Modul „mod_headers“ nicht aktiviert. Dies kann man nachholen, in dem man in der Konsole „sudo a2enmod headers“eingibt. Jetzt sollte der Apache2-Neustart fehlerfrei laufen.

Und wie testet man jetzt, ob die Änderung wirklich aktiv ist? Hier gibt es eine Testseite, in der man sich den HTTP-Header des eigenen Webservers (und natürlich jedes anderen Webservers der Welt) ansehen kann. Dort sollte jetzt die Zeile

X-Frame-Options: SAMEORIGIN

erscheinen.

Übrigens: Wenn Sie keinen Zugriff auf die Servereinstellungen Ihres Webspaces haben – man kann auch mit .htaccess das Kapern Ihrer Webseiten mit Frames verhindern. Die hinzuzufügende Zeile lautet: Header append X-FRAME-OPTIONS „SAMEORIGIN“

Ach ja, und wo wir schon mal dabei sind: Wenn Sie in der Auflistung des HTTP-Headers die Zeile sehen: „X-Powered by“ – und dahinter Ihre detaillierte PHP-Version (ein Freudenfest für Hacker!), sollte man das schleunigst in der php.ini abschalten, indem man in der Zeile expose_php = On das „On“ durch ein „Off“ ersetzt.

WordPress: Upload-Limit erhöhen

In einer neuen WordPress-Umgebung mit podPress stand ich vor dem Problem, dass das vom Hoster vorgegebene Limit von Uploads per PHP-Funktionen – 8 MB – zu klein war (meine Podcast-Audiodateien sind bei Weitem größer). Auf der Medien-Upload-Seite in WordPress nervte schon die warnende Fußzeile „Maximale Dateigröße für Upload: 8 MB.“ Auf die php.ini meines Webpacks habe ich keinen Zugriff, somit konnte ich so ohne Weiteres dieses Limit nicht erhöhen.

Aber es gibt eine einfache Lösung, wie man dieses Limit aushebeln kann: wieder einmal htaccess. Man schreibt einfach eine Datei „.htaccess“ mit folgendem Inhalt:

<IfModule php5_module>
php_value upload_max_filesize 60M
php_value post_max_size 60M
php_value max_execution_time 1200
php_value max_input_time 1200
</IfModule>

Diese .htaccess lädt man dann per FTP in das WordPress-Unterverzeichnis „wp-admin“ hoch, und schon ist das Upload-Limit auf 60 MB heraufgesetzt. Außerdem hat man nun 1.200 Sekunden (20 Minuten) Zeit für den Upload größerer Dateien. Natürlich könnte ich vorab große Audiofiles auch per FTP uploaden und den entsprechenden Path dann im Blogbeitrag in WordPress einbinden. Aber is doch schöner so, nä?

Ich hoffe, dass Ihr Webhoster solche .htaccess-Spielchen ebenfalls zulässt. Wie ich hörte, funktioniert das nicht überall. Also: Ausprobieren.

Verzeichnisinhalte auf dem Webserver verstecken

Heute mal ein Thema aus der Kategorie „Wie war das nochmal?“ – es gibt halt Dinge, die macht man nicht jeden Tag und muss man immer wieder nachlesen. Und jetzt auch wieder sowas. Wovon spricht der Mann? Also: Häufig stößt man beim Surfen auf Webseiten, bei denen eine HTML-Seite nicht mehr vorhanden ist und stattdessen die Dateien eines Ordners auf dem Webserver angezeigt werden. Das ist nicht nur unprofessionell, sondern möglicherweise auch eine Sicherheitslücke, denn die Inhalte der angezeigten Dateien können u. U. viel über die Server- und Websitekonfiguration verraten (insbesondere bei PHP-basierten Sites).

Verzeichnis des Webservers

Sowas sollte man NIE sehen können!

Wenn ich also einen Unterordner auf einem Server à la „http://www.ihredomain.de/verzeichnis“ ansurfe, in dem z. B. keine index.html liegt, kann es passieren, dass mir die Dateien angezeigt werden, die in diesem Verzeichnis liegen. Da hat sich der Administrator wohl wenig um Sicherheit gekümmert – oder schlicht und einfach gepennt. Wie kann man das also verhindern? Mehrere Möglichkeiten:

1. Wenn man selber den Webserver betreibt (bei mir ein Apache2 unter Linux), trägt man in der Konfigurationsdatei des Apache – früher war das mal „httpd.conf“, in aktuellen Distris findet man diese meist als „/etc/apache2/sites-available/default“ – Folgendes ein:

<Directory „/var/www“>
Options -Indexes
Order allow,deny
Allow from all

</Directory>

Wenn man nach einem Apache-Neustart o. g. Ordner ansurft, erhält man eine Fehlermeldung „403 – Forbidden“. Dies betrifft übrigens alle Ordner der Website, in denen keine index.html o. ä. vorhanden ist. Für einzelne Ordner kann man, so gewünscht, diesen Zugriff wieder einschalten, z. B. für einen Downloadordner:

<Directory „/var/www/downloads“>
Options +Indexes
Order allow,deny
Allow from all
</Directory>

2. Diese Möglichkeit habe ich eigentlich schon verraten: wenn in einem Verzeichnis keine index.html vorhanden ist, legt man dort ganz einfach eine solche ab. Diese kann auch leer sein. Ruft man mit dem Browser ein solches Verzeichnis auf, erscheint schlicht eine weiße Seite – eben die leere index.html. Das ist natürlich nicht sehr benutzerfreundlich, denn der geneigte User weiß nicht, warum er nur eine leere Seite bekommt. Daher sollte in dieser index.html z. B. drinstehen, warum hier nichts angezeigt wird. Oder man leitet per Meta-Refresh gleich auf die Startseite weiter.

3. Legen Sie in das Hauptverzeichnis Ihres Webservers eine Datei .htaccess ab und schreiben Sie in diese folgende Zeile hinein: Options -Indexes Dies hat den selben Effekt wie unter Punkt 1 beschrieben: in sämtlichen Unterverzeichnissen werden keine Dateien im Browser mehr angezeigt (Spezialisten wissen, wie man auch hier mittels .htaccess-Steuerung gleich auf die Startseite weiterleitet). Ausnahmen mit Verzeichnis-Zugriffserlaubnis kann man im jeweiligen Ordner einrichten, wenn man dort eine eigene .htaccess-Datei speichert und dort die Zeile Oprion +Indexes hinzufügt. Voraussetzung ist natürlich, dass Ihr Webserver (oder Ihr Hoster) .htaccess unterstützt. Wie man .htaccess – so denn notwendig – auf dem Apache2 aktiviert, habe ich in einem früheren Beitrag schon einmal beschrieben. Wenn man es nun noch ein wenig weitertreibt, kann man sich auch noch eine schicke Standard-Fehlermeldung-403-Seite basteln.

IPv6 und Firefox unter Linux

Ich habe auf einem neuen Notebook ein frisches LinuxMint 15 aufgesetzt und verschiedene Browser eingespielt, wie man das so als Webdeveloper macht. Ich habe in meinem Intranet eine Webseite, auf der angezeigt wird, ob man mit IPv4 oder IPv6 ankommt (auch hier auf der Blogseite unten links gibt es sowas). Nun fiel mir auf, dass der Firefox mir an der Stelle ansagt, ich käme lediglich mit IPv4 an. Die anderen Browser (SRWIron, Opera) zeigten mir hingegen an: alles ok mit IPv6. Wat is dat dann???

Die Lösung: bei der Firefox-Installation in Linuxmint ist standardmäßig die Suche nach einem IPv6-DNS abgeschaltet – warum auch immer. Ändern kann man das wie folgt: in der Adresszeile vom FF „about:config“ eingeben. Die Warnung „Hier erlischt eventuell die Garantie“ ignorieren wir geflissentlich. Nun geben wir in der Suchzeile den Begriff „ipv6“ ein. Nun landen wir auf einer einzigen Zeile „network.dns.disableIPv6“. Der Wert steht mit Sicherheit auf „true“. Doppelklick drauf – dann steht der Wert auf „false“. Browser neu starten – und nun kann der Feuerfuchs auch IPv6. Echt jetzt!

Älteres jQuery, fadeIn/fadeOut und der Internet Explorer

Kinners, nee! Was habe ich mich heute mal wieder über den Internet Explorer geärgert! Aber was soll man machen – es gibt ja immer noch unbedarfte Mitmenschen, die nur diesen so genannten Browser kennen, und auf die muss man auch eingehen. Und das kostet – vor allem Zeit.

Was ist passiert? Ich arbeite mitunter gern mal mit den Animationsfunktionen der JavaScript-Bibliothek jQuery. So habe ich schon vor fast einem Jahr für eine Freundin eine Seite gebastelt, in der unsere gemeinsamen Urlaubsfotos in Form einer Diashow mit Überblendeffekten ablaufen sollten. jQuery-Funktionen der Wahl waren ‚fadeIn‘ und ‚fadeOut‘. Hat auch alles wunderbar funktioniert – einmal mit Opera, Firefox und Co. getestet, der Freundin den „geheimen“ Link geschickt zum Anschauen – abgehakt und vergessen. War ja nur für uns so …

Nun habe ich dieser Tage eine Seite für ein etwas größeres Publikum entwickelt, in der ich eine ähnliche Diashow meinen Vereinsfreunden präsentieren wollte. Und da ich das Rad nicht neu erfinden wollte, habe ich eben besagte Webseite von damals als Vorlage genommen. Hat auch alles soweit funktioniert – bis ich dann mal auf die glorreiche Idee kam, auch mal mit dem Internet Explorer draufzusehen. Und erst da sah ich: im IE blendet nichts über – die Bilder werden einfach nacheinander übereinander gelegt. Ganz normale IE-Bugs eben :-/

Ich habe dann eine Reihe von CSS-Workarounds ausprobiert mit „filter:inherit“, „opacity: inherit“, mit verschachtelten divs als nachzuladendem Hintergrundbild usw. Krampf eben. Dabei ist die Lösung soooooo einfach:

Ich benutzte vor einem Jahr die jQuery-Version 1.2.6, die solche typischen Fehler im Internet Explorer noch nicht berücksichtigte. Ich habe dann eine etwas neuere Version eingespielt (1.7.2) – im HTML-Code im <head>-Bereich entsprechend angepasst, und siehe da: jetzt spielt auch der zickige IE die Diashows flüssig ab – siehe http://meikelcam.bplaced.net/dk7lj .