Freitag, 3. Juli 2009

Tomcat JNDI Realm

Man man Tomcat nicht nur gegen Datenbanken authentifizieren lassen sondern auch gegen andere Naming and Directory Services. Hier ein Beispiel für die Authentifizierung gegen einen LDAP-Server:

<Realm

className="org.apache.catalina.realm.JNDIRealm"

connectionURL="ldap://ldap.rostock.xxx.de"

userPatter="|(cn={0},ou=XXX,o=XX1)(cn={0},ou=XX1,o=XXX)(cn={0},ou=XXX,ou=XY,o=XX1)(cn={0},ou=XX1,ou=XY,o=XY)"

userRoleName="SmartBluUserRole"

roleSearch="(uniqueMember={0})"/>


Jetzt muss man nur noch das formulieren des LDAP-Such-Pattern beherrschen.

Tomcat JDBC Realm

Mit Hilfe des JDBC Realms kann man in Tomcat sehr einfach und elegant eine Benutzerauthentifizierung und Zugriffsteuerung durchführen, bzw. von Tomcat durchführen lassen. Dafür muss man in der Datei context.xml der Webapp folgenden Abschnitt einfügen:

<Realm className="sb.realm.SmartBLURealm" debug="99"

driverName="com.mysql.jdbc.Driver"

connectionURL="jdbc:mysql://localhost:3306/test"

connectionName="smartblu"

connectionPassword=""

userTable="USER"

userNameCol="LoginName"

userCredCol="Password"

userRoleTable="user_roles"

roleNameCol="role_name"

digest="sha"/>


Tomcat versucht dann die Benutzer zu Authentifizieren gegen eine Datenbank jdbc:mysql://localhost:3306/test mit den entsprechenden Parametern. Der Datenbank-Table heisst hier USER. Die Passwörter der Benutzer sind mit SHA gehasht. SHA bedeutet in der Java-Welt meines Wissens nach SHA2.


In diesem Beispiel wir nicht der normale JDBC Realm verwandt sondern ein eigener Realm, der von JDBC Realm abgeleitet wurde aber gleichzeitig ein Migrationsfunktion (das Altsystem verwendete nicht SHA sondern Crypt) besitzt. Die Jar-Datei die die hier verwandte Klasse enthält muss für Tocat verfügbar sein, sie muss sich also im Verzeichnis tomcat/libs befinden. Alternativ kann in dieses Beispiel auch der JDBC Realm (org.apache.catalina.realm.JDBCRealm) eingetragen werden.


Der Realm ist aber nur ein Baustein bei der Authentifizierung mit Tomcat. Die weiterne Bausteine (Login-Config, Rollen und Security Constraints) sind in der Datei web.xml des Projektes enthalten.

Fluent Interface - schlechter Stil hat einen Namen

Gester oder war es Vorgestern bin ich gleich zweimal auf ein Problem gestossen, dass einige Programmierer in einer Codezeile lange, komplexe, häufig ineinander geschachtelte Anweisungen schreiben. In einigen Fällen sieht da sehr elegant aus und es spart Platz, d.h. man muss nicht so viel scrollen im Editor. Diese Art des Code Schreibens hat aus meiner Sicht zwei Mankos, auch wenn ich weniger scrollen muss sinkt die Verständlichkeit des Codes und wenn ein Fehler in dieser Zeile auftritt (Nullpointer in Zeile 137), muss diesen Ausdruck zerlegen um den Bug zu finden. Aus diesem Grund halte ich auch trinäre Ausdrücke für potentielle Fehler.
Daraufhin habe ich in der Newsgroup de.comp.lang.java den Verweis auf die Idee des Fluent Interface gefunden. Die oben beschrieben Art der Programmierung ist kein Fluent Interface. Fluent Interface ist eine elegante Art der Programmierung die vor allem Domain-spezifisch, sehr effizient sein kann. Der Vorteil der Natürlichsprachlichkeit dieser Ausdrücke halte ich nicht unbedingt für einen Vorteil, das mag vielleicht auch mit mit meinen mit Lingo (Macromedia Director, jetzt Adobe Director) gemachten Erfahrungen zusammenhängen. Die Natürlichsprachlichkeit war ja ein Kernfeature von Lingo.

Texte für LaTeX-Dokumente schreiben.

Die aktuellen Office-Pakete glänzen heute durch eine recht gute Rechtschreib- und Grammatikprüfung, ein Feature das vielen LaTeX-Editoren fehlt. Ein Möglichkeit dies zu kompensieren ist die Verwendung von Open Office mit der Erweiterung Writer2LaTeX. Mit ihr kann man Open Office Textdokumente als LaTeX-Dokumente exportieren.