PHP. Kennt Ihr die Situation, wenn man sich am Wochenende um seine Altlasten alten Applikationen und Software-Tools kümmert. Genau das mache ich gerade. Und ich stelle fest: “I hate PHP.” Diesen Mist trage ich nun seit dem ersten Semester mit mir rum. Und wenn man es genau betrachtet, dann ist PHP eine Skriptsprache, die zwar für einfache Dinge (wie z.B.: Blogs) durchaus geeignet ist. Aber sobald mal etwas komplexer wird, erfordert PHP oberste Disziplin, damit die Applikationen auch zukünftig gut wartbar bleiben. Professionelles WebDevelopment wird eben nicht mit PHP gemacht. Ich für meinen Teil empfehle Java/Spring WebMVC und Python/Django (plus eventuell Pinax). Java ist typsicher und stabil. Allerdings ziehen die meisten Java-Projekte auch immer einen riesigen Boilerplate-Code-Rattenschwanz hinter sich her. Wesentlich felxibler und schneller ist man mit Python/Django. Genau aus diesem Grund werde ich meine Webapps alle auf Python/Django umstellen. Dann bin ich den bösen Fluch PHP los.

WTF? Bye Bye PHP? Es gibt jetzt eine WordPress-Variante aus Java auf Basis des Spring MVC Frameworks. KLicht gut, oder? Das Ding heißt nWordPress und wurde von numiton.org released. Numiton hat sich auf die Fahne geschrieben Open Source Projekte, die PHP entwickelt wurden, auf Java umzustellen. Komische Idee. Aber sie bringt auch Vorteile mit, denn schließlich werden die “Gefahren von PHP” so ganz gut umgangen. Ich glaube heute abend schaue ich mir mal den Source von dem Ding an. Wenn das sauber umgesetzt ist, dann kann man damit sicher ne Menge Spaß haben. Ich brauche sowieso einen neuen Blog: Den “PhilDevBlog”.

Nachdem ich mich nun den dritten Abend in Folge mit dem Django Web Framework beschäftige, muss ich feststellen:

Django rawks!
(bedeutet so viel wie: Django rocks! xD)

Das Django Web Framework wirklich nice. Eine Web Applikation ist innerhalb weniger Minuten aus dem Boden gestampft. Ich muss mich nicht mehr um die Datenbank kümmern. Das tut Django nun für mich. Ich muss mir für meine Web Applikationen kein Admin-Frontend mehr basteln. Das tut Django nun für mich. Eleganz hat einen neuen Namen: Django. Ich bleibe dran… Meine nächste Webapp werde ich definitiv mit Django bauen.

Vor wenigen Minuten habe ich entdeckt, dass die Version 1.0 vom Django Web Framework endlich released wurde. Das riecht förmlich nach einer kleinen Testsession. Ich habe es mir gerade Mal runtergeladen und schwinge mich nun auf meinen Gaul um mit Django zusammen durch die Prärie zu reiten.

Wenn man sich einen neuen Apache Tomcat installiert und versucht auf das Manager-Servlet (http://[Host]:[Port]/manager/html) zuzugreifen, wird man per Default von der folgenden wunderbaren Meldung begrüßt:

HTTP Status 403 – Access to the requested resource has been denied

Woran liegt das!?

Ganz einfach: Das ist ein Sicherheits-Aspekt. Der Nutzer des Tomcats soll die Konfiguration selbst vornehmen, damit der Tomcat produktiv niemals mit einem Default-Manager-User eingesetzt wird. Die Datei tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) sieht per Default wie folgt aus:

1
2
3
4
5
6
7
8
9

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
</tomcat-users>

Man erkennt auf den ersten Blick: Da gibt es ja gar keinen Manager-User. Aha!

Aber was ist zu tun, wenn man nun doch die Manager-Applikation nutzen möchte!?

Auch das ist wieder denkbar einfach. Man fügt einfach einen neuen Tomcat-User mit einer Manager-Rolle ein. Dazu muss die tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) wie folgt angepasst werden:

1
2
3
4
5
6
7
8
9
10
11

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="manager" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
    <user username="manager" password="manager" roles="manager,admin" />
</tomcat-users>

Danach muss der Tomcat neu gestartet werden, so dass die Einstellungen übernommen werden können. Jetzt kann man sich mit dem User “manager” und dem Passwort “manager” bequem ins Manager-Servlet einloggen.

Wichtig!

Bevor der Tomcat produktiv eingesetzt wird, sollte diese Änderung jedoch abgewandelt oder rückgängig gemacht werden, da sonst von außen auf das Manager-Servlet zugegriffen werden könnte und ganze Anwendungen undeployt (vom Server entfernt) werden können.

Warum schreibe ich das hier?

Ich habe diese Lösung schon mehrfach gegoogelt und muss irgendwie jedes Mal wieder nachschlagen. Und weil mich das so nervt, pumpe ich die Lösung jetzt in meinen Blog, dann weiß ich wo sie steht.