Adding LDAP Authentication to a Play! 2 Application

Flattr this!

As of Play! 1 is not really supported anymore, i will describe the steps for accessing Data from your LDAP Directory with your Play! 2 with this Post.


As also mentioned in my last Post, for this example we are using the Vagrant vagrant-rundeck-ldap VM, I already mentioned here.


After you setup a basic Play! 2 Application with

play new ldap-test

We need to update our Applications Dependencies. To achieve this, we need to change project/Build.scala:

import sbt._
import Keys._
import play.Project._

object ApplicationBuild extends Build {

  val appName         = "play2-ldap-example"
  val appVersion      = "1.0-SNAPSHOT"

  val appDependencies = Seq(
    // Add your project dependencies here,
    "com.innoq.liqid" % "ldap-connector" % "1.3"

  val main = play.Project(appName, appVersion, appDependencies).settings(
    // Add your own project settings here      

The Command:

play compile

Should download all necessary Project Depedencies and will do an initial Compilation of all your Project Files (currently not really many).

You also need to add the LDAP Settings to your Applications configuration. For this example we will use an external Properties File conf/

# Settings for LiQID
# ~~~~~

# LDAP Listsing, divided by ","




Since Play1 2 does not really support the use of Before Filters, we will use Custom Actions for making our Login Authentication work.
We will create a new Package app/actions with two new files: an annotation interface BasicAuth and the implementation itself BasicAuthAction.
Annotations will be used to Set a specific Controller to use Basic Auth.
So lets start with BasicAuth:

package actions;

import play.mvc.With;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target({ ElementType.METHOD, ElementType.TYPE })
public @interface BasicAuth {

After that you can annotate Controllers with @BasicAuth (but this won’t work, since the Implementation is still missing).
Here then the BasicAuthAction:

package actions;

import com.ning.http.util.Base64;

import models.User;
import play.mvc.Action;
import play.mvc.Http.Context;
import play.mvc.Result;

public class BasicAuthAction extends Action {

	private static final String AUTHORIZATION = "authorization";
	private static final String WWW_AUTHENTICATE = "WWW-Authenticate";
	private static final String REALM = "Basic realm=\"play2-ldap-example\"";

	public Result call(Context context) throws Throwable {

		String authHeader = context.request().getHeader(AUTHORIZATION);
		if (authHeader == null) {
			return sendAuthRequest(context);

		String auth = authHeader.substring(6);

		byte[] decodedAuth = Base64.decode(auth);
		String[] credString = new String(decodedAuth, "UTF-8").split(":");

		if (credString == null || credString.length != 2) {
			return sendAuthRequest(context);

		String username = credString[0];
		String password = credString[1];
		User authUser = User.authenticate(username, password);
		if (authUser == null) {
			return sendAuthRequest(context);

	private Result sendAuthRequest(Context context) {
		context.response().setHeader(WWW_AUTHENTICATE, REALM);
		return unauthorized();

As you can see, there are no LDAP specific Dependencies at all, since all necessary Logic is the User Model, in User.authenticate(username, password).So let’s have a look into that Model:

package models;

import play.Play;

import com.innoq.ldap.connector.LdapHelper;
import com.innoq.ldap.connector.LdapUser;
import com.innoq.liqid.utils.Configuration;

public class User {

	private static LdapHelper HELPER = getHelper();

	public String sn;
	public String cn;
	public String dn;

	public User(String cn) { = cn;

	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("cn: ").append(cn).append("\n");
		sb.append("sn: ").append(sn).append("\n");
		sb.append("dn: ").append(dn).append("\n");
		return sb.toString();

	public static User authenticate(String username, String password) {
		if (HELPER.checkCredentials(username, password)) {
			return new User(username);
		return null;

	public static User getUser(String username) {
		LdapUser ldapUser = (LdapUser) LdapHelper.getInstance().getUser(
		User user = new User(username); = ldapUser.get("cn"); = ldapUser.get("sn");
		user.dn = ldapUser.getDn();
		return user;

	private static LdapHelper getHelper() {
				+ "/conf/");
		return LdapHelper.getInstance();

You also have a static Instace of that LDAP Helper, but authenticate User Credentials and Login are in two different Methods.Last thing is to Load a User from the LDAP Directory:Here the Admin Controller:

package controllers;

import models.User;
import actions.BasicAuth;
import play.mvc.Controller;
import play.mvc.Result;
import views.html.Admin.index;

public class Admin extends Controller {
    public static Result index() {
    	User u = User.getUser(request().username());
        return ok(index.render("Hello Admin!", u));

And here the used Template File:

@(message: String, user: User)

@main("Admin Index") {


You can find the Sources of that Library here: can find an example Project here:


Flattr this!

This Module provides support for converting Play! i18n Files into an Excel Sheet and from an Excel Sheet to i18n Files.


You need to create the message files first (e.g. conf/messages, conf/, conf/messages.en)
You may enter some key/value entries to the Files.

The prefered format is:

# Description key=value 

Add the Module to your dependencies:

... - local -> i18ned 0.1 
... repositories: 
    - local: 
          type: local
          artifact: ${application.path}/../modules/[module]/dist/[module]-[revision].zip 
     contains: - local -> * 

Then install the Module

play deps --sync 

Export (creating Excel File)

play i18ned:export 

Your will find the Excel File in APP_DIR/tmp/i18n.xls

Import (Moving Changes from the Excel File into the Messages Files)

play i18ned:import 


  • Adding SQL-Export with SQL-Templates
  • Adding Support for selective Actions (Im/Export only specific files)
  • Import from other i18n Formats


Building Native MacOS Apps with Java

Flattr this!

Some Time ago, Java and MacOS were friends. You could just open XCode choose “Java Application” and start coding your app. But since the last version of Xcode 3 and finally with the release of Xcode 4 all the nice Cocoa/Java Bindings were gone. The normal way of Apple to cleanup their System and make space for the support of new Features.

But sometimes you have this great Java Library. Or you just want to create a nice UI for your CLI Java App, and the common SWING UI won’t work and other UI Libraries like macwidgets just lack support for a decent UI Designer and will just add some more graphics to your plain Java UI.

There is a solution for that kind of Problem. It is called rococoa and offers Java a native Binding to your Cocoa Libs. There is also one famous Application that uses this Library and doing very well: Cyberduck.
This App also managed to get into the _AppStore_ by Bundling its own JDK to the App Bundle. You can see the source of Cyberduck here.

So What is an App Bundle?

An App Bundle is basically just a folder with an .app in its nahe. It contains some common Folders:

– a Content Folder with
-> a plist File
-> a Resources Folder

App Bundle Structure








There is an old Project called JarBundler to create MacOS App Bundles from your Java Project.
But for this example we are using the maven plugin “osxappbundle-maven-plugin”, for creating the App Bundle and a DMG File for Installation. We also adding the necessary Files for ROCOCOA.

The first Step is to create the necessary NIB File for our Application. In Xcode 3 you could just create a basic NIB with Interface Builder and then add the Outlets and Actions to the NSObject Class (that is the default First Responder). In Xcode 4+ you need to create a dummy controller Class first. Then you can add your Outlets to this class and the the first Responder to this Class.

XCode 4+ NIB and Dummy Class









You can now create your ViewController Class in Java:

// we re-using some of the work done by the cyberduck developer.
import ch.cyberduck.ui.cocoa.application.NSTextField;
import ch.cyberduck.ui.cocoa.application.NSWindow;

import org.rococoa.ID;
import org.rococoa.Rococoa;

public class WindowController {

    public WindowController() {
        String bundleName = "HelloWorld";
        // Load the NIB file and pass it our Rococoa proxy as the file owner.
        if (!NSBundle.loadNibNamed(bundleName, {
            System.err.println("Couldn't load " + bundleName + ".nib");
    // Injected outlet from NIB
    private NSWindow mainWindow;

    private NSTextField textField;

    // Called when loading NIB using NSBundle. NIB has a mainWindow outlet defined.
    public void setMainWindow(NSWindow mainWindow) {
        System.out.println("Outlet set to: " + mainWindow.title());

    // bind the Outlet to the Class Attribute.
    public void setTextField(NSTextField textField){
        this.textField = textField;

    // NSButton in NIB has an action to the file owner named buttonClicked:
    public void buttonClicked(ID sender) {
        textField.setStringValue("Hello World from: " + sender);

     * You need to keep a reference to the returned value for as long as it is
     * active. When it is GCd, it will release the Objective-C proxy.
    private NSObject proxy;
    private ID id;

    public NSObject proxy() {
        return this.proxy(NSObject.class);

    public NSObject proxy(Class type) {
        if (null == proxy) {
            proxy = Rococoa.proxy(this, type);
        return proxy;

    // Getter for ID for Rococoa Binding
    public org.rococoa.ID id() {

    // Setter for ID for Rococoa Binding
    public org.rococoa.ID id(Class type) {
        if (null == id) {
            id = this.proxy(type).id();
        return id;

Your main methode is very simple. It just calls the ViewController and creates the AutoreleasePool for your App:

import ch.cyberduck.ui.cocoa.application.NSApplication;

 * Hello world!
public class App {
    public static void main(String[] args) {
        final NSAutoreleasePool pool = NSAutoreleasePool.push();
        try {
            // This method also makes a connection to the window server and completes other initialization.
            // Your program should invoke this method as one of the first statements in main();
            // The NSApplication class sets up autorelease pools (instances of the NSAutoreleasePool class)
            // during initialization and inside the event loop—specifically, within its initialization
            // (or sharedApplication) and run methods.
            final NSApplication app = NSApplication.sharedApplication();
            WindowController w = new WindowController();
            // Starts the main event loop. The loop continues until a stop: or terminate: message is
            // received. Upon each iteration through the loop, the next available event
            // from the window server is stored and then dispatched by sending it to NSApp using sendEvent:.
            // The global application object uses autorelease pools in its run method.
        } finally {

I am using an updated version of this example from the rococoa Project Page.

Finally you have to put all the things together; Compiling your Java Files, adding your native Libs, Creating your App-Bundle and your DMG.
I updated the Plugin to be able to add non Java Dependencies to Your App Bundle (like dylibs and NIB Files). You can find the updated version here. I am currently working on creating patch files for upstreaming my changes to the codehaus project.

The important Call of the Maven-Plugins reads like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<project xmlns="" xmlns:xsi="" xsi:schemaLocation="">
    <name>Hello World</name>
                    <!-- PLIST Settings -->
                    <vmOptions>-Xmx512m -Djava.library.path=$APP_PACKAGE/Contents/Resources/Java/lib -Djna.boot.library.path=$APP_PACKAGE/Contents/Resources/Java/lib -Djna.library.path=$APP_PACKAGE/Contents/Resources/Java/lib -Djna.nounpack=true -Djava.awt.headless=true -Dsun.jnu.encoding=utf-8 -Dfile.encoding=utf-8 -XX:-UsePerfData -XX:+ReduceSignalUsage -Xincgc -XX:-UseLoopPredicate -XX:-OptimizeStringConcat</vmOptions>
                    <!-- adding additional files to the DMG -->
                    <!-- Adding additional Resources (like NIBs) -->
                    <!-- Adding Native Java Libs -->
            <name>javastream Repository</name>


You can find the whole project on Github. It is a very simple Hello World Programm. As soon as you click the Button the Labels text changes to “Hello World from: #CALLER-ID”.

App Window









The next step is to do further updates to the Plugin, for Bundling a JDK to your App Bundle for creating a real Standalone Application.

Fixing Redirects of a Play! App behind an Apache2 SSL Proxy

Flattr this!

So you just finished your first Play! App. You want to run that thing behind an Apache2 as a HTTPS Proxy, because you do not want, that your User-Credentials are read as clear text.

So a very basic Apache Configuration looks like this:

    <IfModule mod_ssl.c>

        Listen 443
        SSLRandomSeed startup builtin
        SSLRandomSeed connect builtin

        <VirtualHost _default_:443>

            SSLEngine on
            ErrorLog /var/log/apache2/ssl_error_log

            SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
            SSLCertificateFile /etc/apache2/ssl/example/newcert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/example/webserver.nopass.key
            SSLCACertificateFile /etc/apache2/ssl/demoCA/cacert.pem
            SSLCARevocationPath /etc/apache2/ssl/certs/demoCA/crl

            ProxyPass               /play  
            ProxyPassReverse        /play  



I did already explained how to run a Play! Application within a Application Context. Here our Context is just “play”, but you can set it to something else. You can also change and add seperate instances with different ports (over 9000!!!).

You should alter two settings in your conf/application.conf

    # you need to add this

    # you need to uncomment this to prevent Play! from serving aside your Apache2 Proxy

   # you may uncomment and change this port number for chaning it
   # http.port=9000

Time for a Test Run. At a first glance it seems to work pretty nice. But as soon as you want to use the nifty routing redirects from Play!, the whole system breaks, because Play! still things, it runs in plain http on port 9000. To solve this, you need to change to things:

  1. Make Apache2 to send a specific header, that the Request was send through a Proxy
  2. Make Play! to fix the redirect to the correct URL

The first part is pretty easy. Just add

    RequestHeader set X_FORWARDED_PROTO 'https'

within your VirtualHost Tag – you may need to enable the headers module first to make that work.

The second part is a little bit more difficult. You have to add a before filter to your application controller:

    public class Application extends Controller {

        private static void checkSSL() {
            if (request.headers.get("x_forwarded_proto") != null
                    && "https".equals(request.headers.get("x_forwarded_proto").value())) {
       = true;
                request.port = 443;
            if (request.headers.get("x-forwarded-server") != null) {
                request.domain = request.headers.get("x-forwarded-server").value();

You can find the sources on GitHub.
B.t.w. the same problem also might appears in Rails Apps, i might write about this later on.

Hacking just for Fun: Get Mails from IMAP with Java

Flattr this!

I have the feeling, that i might need this someday :-).

Collecting Mails from an IMAP Server with Java is pretty easy:

package de.javastream.imapcollector;

import java.util.Properties;
import javax.mail.Folder;
import javax.mail.Message;
import javax.mail.Multipart;
import javax.mail.Part;
import javax.mail.Session;
import javax.mail.Store;
import javax.mail.internet.MimeBodyPart;
import javax.swing.JOptionPane;

public class App {

    public static void getMail(String host, String user, String passwd) throws Exception {
        Session session = Session.getDefaultInstance(new Properties());
        Store store = session.getStore("imap");
        store.connect(host, user, passwd);
        Folder folder = store.getFolder("INBOX");;
        // the funny part is... you can count all the messages before you download them.
        Message[] messages = folder.getMessages();
        System.out.println("there are "+messages.length+" in your INBOX.");
        for (int i = 0; i <; messages.length; i++) {
            Message m = messages[i];
            System.out.println("Nachricht: " + i);
            System.out.println("From: " + m.getFrom()[0]);
            System.out.println("Subject: " + m.getSubject());
            // some Messages are multipart messages (e.g. text with an attachement)
            if (m.getContentType().equals("multipart")) {
                Multipart mp = (Multipart) m.getContent();
                for (int j = 0; j <; mp.getCount(); j++) {
                    Part part = mp.getBodyPart(j);
                    String disposition = part.getDisposition();
                    if (disposition == null) {
                        MimeBodyPart mimePart = (MimeBodyPart) part;
                        if (mimePart.isMimeType("text/plain")) {
                            BufferedReader in = new BufferedReader(
                                    new InputStreamReader(mimePart.getInputStream()));
                            for (String line; (line = in.readLine()) != null;) {
            } else {
        System.out.println("done :-)");

    public static void main(String[] args) throws Exception {
        // show some simple Dialogs to get server, username and password
        String server = JOptionPane.showInputDialog("enter your Mail Server e.g.");
        String user = JOptionPane.showInputDialog("enter your login e.g. user");
        String password = JOptionPane.showInputDialog("enter your mail password");
        getMail(server, user, password);

Becource you will need the java mail lib as a dependency i just created a small maven project to add them.
Just unzip it and run

mvn exec:java

Download Maven Project for ImapCollector

A Colleague of mine asks for the imports of that Code. I just added them to the sources. You have to include the javamail lib from Sun Oracle as a dependency to run the code.

Hacking just for Fun: Raid5 in Java

Flattr this!

I was just curious how easy it might be to write a RAID5 compatible Outputstream in Java? Just a few Lines. For sure it is not the most elegante solution. Especially if you see the nice possibility to integrate one Outputstream within another… so maybe two Raid5s into one Raid0 Stream? (would be RAID50) then. Reading is missing ;-).

 * Raid5Stream
 * 31.03.2012
 * @author Philipp Haussleiter
package de.javastream.jraid;


public class Raid5Stream extends OutputStream {

    public final static int PARITY_MARKER = 1;
    public final static int DATA_MARKER = 0;
    private File disks[];
    private FileOutputStream streams[];
    private int mode = 0;
    private final static int MAX_MODE = 2;
    private int[] buffer = new int[2];

    public Raid5Stream(File disks[]) throws IOException {
        if (disks.length != 3) {
            throw new RuntimeException("we need a disk count of x times 3");
        int i = 0;
        this.disks = new File[disks.length];
        this.streams = new FileOutputStream[disks.length];
        for (File f : disks) {
            if (!f.exists() && !f.createNewFile()) {
                throw new RuntimeException(f.getAbsolutePath() + " does not exists and cannot be created!");
            } else {
                System.out.println("using " + f.getAbsolutePath() + "\n");
                this.disks[i] = f;
                this.streams[i] = new FileOutputStream(f);

    private void writerMarker() throws IOException {
        for (int i = 0; i < this.streams.length; i++) {
            if (i % 3 == 0) {
            } else {

    public void write(int i) throws IOException {
        switch (mode) {
            case MAX_MODE:
                this.streams[mode].write(buffer[0] ^ buffer[1]);
                mode = 0;
                this.buffer[mode] = i;

Using it is easy as:

public class App {

    public static void main(String[] args) throws IOException {
        File raid5_disk1 = new File("raid5.disk1");
        File raid5_disk2 = new File("raid5.disk2");
        File raid5_disk3 = new File("raid5.disk3");
        long count = 0;
        Raid5Stream raid5Stream = new Raid5Stream(new File[]{raid5_disk1, raid5_disk2, raid5_disk3});
        FileInputStream in = new FileInputStream("/dev/random");
        BufferedInputStream bis = new BufferedInputStream(in);
        BufferedOutputStream raid5bos = new BufferedOutputStream(raid5Stream);
        while(count < 1024*1024*2){

Good sources for more reading are the Wikipedia Articles about RAID and XOR.

Run local/remote terminal commands with java using ssh

Flattr this!

Sometimes you need to use some CLI-Tools before you want to create or search for a native JNI Binding.
So there is a common way, using the Java Process-Class. But then you might meet two problems i had to face in the past during several problems:

  1. There are (a really small) number of CLI-Tools, that giving no constant output over the STD-OUT (the standard output the Process-Class uses for output)
  2. There is no “elegant” way to implement a process call into your project.

To solve this Problem I created a basic HelperClass, that calls the System over SSH (with the Convenience to work remote and the side-effect to always get STD-compatible output).
I am primarely using it for a fun project SAM i started some months ago to try to create a Management-Tool for Unices and Windows with a very low client-side footprint.

The first Class is used to capsulate the basic SSH Calls:

// some imports... 
 public class SystemHelper {
    private Runtime r;
    private String sshPrefix = "";

    // call with $user and to run local command.     
    public SystemHelper(String user, String ip) {
        r = Runtime.getRuntime();
        sshPrefix = " ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no " + user + "@" + ip;

    public void runCommand(String command, ProcessParser pp) {
        try {
  "running: " + this.sshPrefix + " " + command);
            Process p = r.exec(this.sshPrefix + " " + command);
            InputStream in = p.getInputStream();
            BufferedInputStream buf = new BufferedInputStream(in);
            InputStreamReader inread = new InputStreamReader(buf);
            BufferedReader bufferedreader = new BufferedReader(inread);
            try {
                if (p.waitFor() != 0) {
          "exit value = " + p.exitValue());
            } catch (InterruptedException e) {
            } finally {
                // Close the InputStream                 
        } catch (IOException ex) {

ProcessParser is an interface that defines the methode parse, accepting a BufferedReader for parsing the output of the Process. Unfortunately there is no timeout ATM to kill a hanging SSH-Call.

 public interface ProcessParser { 
     public void parse(BufferedReader bufferedreader); 

The most basic (Output-)Parser looks like this:

    public String getPublicSSHKey() {
        SimpeOutputPP so = new SimpeOutputPP();
        String command = "cat ~/.ssh/";
        runCommand(command, so);
        if (!so.getOutput().isEmpty()) {
            return so.getOutput().get(0);
        return "";

This returns just the public SSH-Key of the current user. I implemented some more parsers for the output of apt (dpkg), rpm and pacman. You can find them in the github project here.

Counter Update

Flattr this!

I just finished my latest improvements to the legacy version of my counter script.
I just added the lookup for ISPs and added dynamic scaling for the axis legend.
I will now going forward to change the whole system to a more sophisticated software, e.g. using a Datawarehouse approach. The first version of the Data-Model is finished.

So from the old version (that was just some plain tables, flowing around)











I created a new Model with more Tables, connected to each other. Basically i devided the Model into a basic Fact (Count) and some Dimensions (for every Value):











With my current values (around 22k Facts), i have already to limit the facts that are queryed from the Datebase. I wrote a short script to migrate all old Datasets to the new Data-Model.

Testing Play! Applications with HTTP Basic Auth

Flattr this!

Um eine Play!-Anwendung zu testen, welche HTTP-Basic-Auth verlangt ist es notwendig, die Standard-Datei anzupassen:
Verändert werden muss die Test-Methode testThatIndexPageWorks():


    public void testThatIndexPageWorks() {
        Response response = GET("/");
        assertContentType("text/html", response);
        assertCharset(play.Play.defaultWebEncoding, response);


    public void testThatIndexPageWorks() {
        Request request = FunctionalTest.newRequest();
        request.user = "test";
        request.password = "test";
        request.url = "/";
        Response response = GET(request, "/");
        assertContentType("text/html", response);
        assertCharset("utf-8", response);

Wobei User = test und Passwort = test.
Bei allen weiteren Test-Methoden verfährt man analog, oder erstellt sich eine Factory-Methode für den Request.

Play! Applications und der App-Context

Flattr this!

Es ist möglich, eine Play!-Anwendung sehr einfach in eine WAR-Struktur zu übertragen und in einen Application-Server zu deployen.
Dies ist recht gut unter Deployment options in der Play!-Dokumentation recht gut erklärt. Was hier allerdings verschwiegen wird ist, wie man den notwendigen Context beim Routing konfiguriert. (Der Context ist der Pfad der Anwendung, welcher standardmäßig vom Namen des WAR-Archivs abgeleitet wird, oder per Descriptor konfiguriert wird) – heißt das Archiv testapp.war ist der Context /testapp.

Innerhalb einer Play!-App muss der Context sowohl in der Config Datei, als auch im Routing definiert werde:



Danach lässt sich in der routes Datei der Context in die Routen konfigurieren:

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

%{ context = play.configuration.getProperty('context', '') }%

# Home page
GET     ${context}                                        Application.index
GET     ${context}/                                       Application.index

# Map static resources from the /app/public folder to the /public path
GET     ${context}/public/                                staticDir:public
GET     ${context}/Users/like/{uid}             
GET     ${context}/Users/{uid}/show