I’m not going to explain anything that’s already documented for RichUI’s AutoComplete component. Basic formatting customisation is already documented, so if you’re looking to change the colours used or the width of the output then take a look there.

The code I was working on searched a multi-lingual database for words, the initial output being displayed looked like this:

in addition to this, I wanted to display locale flags for the languages alongside the results:

This change would involve modifying, not just the styles, but the actual HTML that was being used to render the results by the AutoComplete component.

The RichUI plug-in is based on the Yahoo User Interface Library or YUI for short. The AutoComplete component in RichUI, is just a Grails tag that creates a YUI AutoComplete component; the documentation for which explains how the HTML for the results list can be customised.

In short, to customise the HTML, there is a method named ‘formatResult‘ on the AutoComplete JavaScript object that gets called to render each of the results. By default, this method just returns the plain text of the result. However, it can be overridden to provide custom mark-up.

The documentation for the RichUI AutoComplete tag explains how a JavaScript function can be registered to handle an ‘onItemSelect’ event, but there is no explanation of how to override any other methods. After a little investigation of the RichUI plug-in code I found that the renderer that produces the HTML for the tag does in fact and associate any attributes declared on the tag as properties/methods on the YUI component. Note that this is not a documented feature, but one I would hope would not be changed in future versions of this plug-in.

So by declaring the RichUI tag like this:

<richui:autoComplete
    name="keywords"
    action="${createLinkTo('dir': 'word/findAjax')}"
    maxResultsDisplayed="20"
    formatResult="myFormatResult"/>

the renderer will generate JavaScript like this; setting not only the formatResult event handler, but the maxResultsDisplayed property too:

autoComplete = new YAHOO.widget.AutoComplete('keywords','...', dataSource);
autoComplete.maxResultsDisplayed = 20;
autoComplete.formatResult = myFormatResult;

it’s then just a matter of implementing a JavaScript function that generates the HTML for each of the items:

function formatResult(oResultData, sQuery, sResultMatch) {
  var sMarkup;
  var locale = oResultData[1];
  var imageUri = "${createLinkTo(dir:'/images/flags')}/" + locale + ".png";
  if (sResultMatch) {
    sMarkup = "<img src=" + imageUri + "/> " + sResultMatch
  } else {
    sMarkup = ""
  }
  return sMarkup;
}

Finally, it’s worth noting here that the data returned from the search controller is available in the ‘oResultData’ array that gets passed in to this function. In this example, you can see that the locale for the word is being accessed and used to generate the image URI.

To achieve this, the response is being generated in the search controller like this:

render(contentType: "text/xml") {
  results() {
    words.each { w ->
      result() {
        name(w.stem)
        id(w.locale)
      }
    }
  }
}

the name and id elements that are being produced in the XML are those specified in the schema that RichUI uses. The name element is the value that is usually displayed by the component, the ID is a supplemental value that is available to the RichUI ‘onItemSelect’ JavaScript event handler. it should be possible to extend this but I’ll leave that challenge for another day…

If you’d like to see this code in action take a look at the Language Spider project web-site.

In this post I’ll demonstrate how the same principle can be applied in a Grails application.

Basically, just about everything from the previous post is the same, except for how the filtering of requests and the sending of the cookies from the host application is performed.

In Grails it is simple to write web filters. Just create a Groovy class with a name that ends with ‘Filters’ in your conf folder and add closures that define the filtering behaviour:

class MyFilters {
    def filters = {
        myFirstFilter(controller: '*', action: '*') {
            before = {
                  //code here is executed before the controller has been accessed
            }
            after = {
                  //code here is executed after the controller has been accessed
            }
            afterView = {
                  //code here is executed after the view has been rendered
            }
        }
    }
}

in this example, there is a single filter called ‘myFirstFilter’ that will be applied to all actions on all controllers, which illustrates the three filtering points available in Grails.

So given a Grails application service called ‘userService’ that returns us a domain object for the currently logged in user, then we could write a cookie sending filter which uses the SSO plug-in like this:

class SecurityFilters {
  def userService;

  def filters = {
    jForumSecureSSOCookie(controller: '*', action: '*') {
      after = {
        if (userService.getUser()) {
          def user = userService.getUser();
          def encryptedValues = SecurityTools.getInstance().encryptCookieValues(user.email, user.username);

          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedValues)
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        } else {
          //user is not logged in so kill the cookie
          //(removing cookies does not work reliably in all browsers)
          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, "")
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        }
      }
    }
  }
}

Because, Grails runs in a Java environment, all other configuration, including the JAR file deployment remain as discussed in the previous post.

As the SSO code I wrote didn’t have any dependency on our applications classes, I decided to package and release it as a JAR file that anyone can use.  If you’d like to use it, then you can download it from the tools page on this website; instructions on how it words and how to configure JForum to use it are detailed below.

Integrating JForum into an existing application

JForum is indented to be used as either a stand-alone forum, or as an integrated solution for existing sites. The simplest way to integrate JForum with an existing application is simply to deploy it as a second named application under the same domain. For example, if your application is running on a server at:

http://www.myapplication.com/

then just run the JForum application under the same domain as a separate application, for example:

http://www.myapplication.com/forum

you can then just link to it from your web pages. Customise the JForum page templates to look like those from your own application and you’re almost done.

The last thing that you’ll want to do is automatically log users in to the forum once they’re logged into your application. If you don’t do this then your users will have to re-register with JForum just to use the forum pages! Fortunately, JForum ships with a simple SSO module. Unfortunately it’s not very secure.

If you’re running JForum on the same domain as the application your are integrating it with, then cookies set by one application will be visible to the other; as far as the browser can tell, its interacting with a single application. The standard SSO solution that ships with JForum exploits this fact and if your application sets a cookie with the user’s screen name and email address, JForum will automatically log them in to the forum pages for you.

This is a neat and simple solution but it does have a real security hole. If a hacker decides that they want to log into the forum and post messages as another user, then all they need to do is make their browser send a cookie with the name and email details of the users account they want access and JForum will then just log them into it. This is easy to do with something like Firefox’s firebug plug-in and doesn’t require any great skill.

JForum does provide an API with hooks for implementing your own SSO integration. In the JForum documentation, the example demonstrates how, in addition to receiving the user’s credentials (again via a plain text cookie), you could make calls to your database to access further user information. This does not address the security issue outlined above. Further work is required to achieve this.

A more secure solution

In the solution I developed, rather than sending a plain text user name to JForum in a cookie, an encrypted value is passed between the applications instead. By using a strong encryption algorithm it is possible to authenticate the user just once in the main application, and then send an encrypted token in the cookie that can be used to authenticate the user in JForum. This approach has the distinct advantage of preventing any hackers from being able to spoof user names by simply sending them in a cookie.

So, for example, if you encrypt your user’s name and email address before sending them in a cookie, anyone examining the cookie data will see something resembling:

b259fa5bb42d8c53280c54bbb16d9b814574443d903eb85ba5594ef58b374c8d

this can be decrypted by JForum and the users name and email address retrieved from it.

Configuring and using the JForumSecureSSO plug-in

The steps involved to use this plug-in are:

1. Change the default encryption password used
2. Install the JAR file in each of the applications
3. Implement a cookie filter for your application
4. Configure JForum to use your encrypted cookie

Lets look at these in more detail:

1. Change the default encryption password used

If you take a look in the META-INF folder in the jforum-secure-sso.jar file you’ll find a properties file that contains a property called security.password. The default value for this property is ‘change this’.

This property value is the password used by the encryption libraries as a seed for the encryption that is carried out on the cookie data. Update the JAR file by changing the password to a value that only you know – you should make this at least 16 chars long.

Note that you won’t use this password anywhere else in your application so you could just enter some random characters here.

2. Install the JAR file in each of the applications

Copy the JAR file with the modified password into the WEB-INF/lib folders of both your application and JForum too. This ensures that the encryption routines in the JAR files will now both be using your secret password when encrypting/decrypting the data.

3. Implement a cookie filter for your application

In order to ensure that an encrypted cookie is sent for any authenticated users, you’ll need to add a little functionality to your application.

There are a number of variations on how you might do this depending on the security system that you are using. For this reason, there are no classes in the JAR file that do this for you – time for you to cut a little code!

Generally, the best way to send the cookie will be from within a Web Filter. These are a standard feature since Servlet 2.3 specification and are are supported by all but the most antique application servers. The filter should be applied to all URLs that your application supports and will need to send an encrypted cookie, something like this:

import uk.co.smartkey.jforumsecuresso.SecurityTools;

//get your user's details from wherever they are available in  your application
User user = session.getAttribute('user');

//encrypt them using your secret password
String encryptedData = SecurityTools.getInstance().encryptCookieValues(user.getEmail(), user.getUserName());

//send the cookie using the predefined cookie name
Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedData)
c.maxAge = -1;
c.path = "/"
response.addCookie(c)

4. Configure JForum to use your encrypted cookie

In the JForum configuration file, you’ll need to set the following properties to ensure that your data is loaded and used to log your users in using SSO:

authentication.type=sso
sso.implementation=uk.co.smartkey.jforumsecuresso.JForumSecureSSO
sso.redirect=http://www.myapplication.com/login.jsp

More details of these settings are available at the JForum web site.

Comments

If you think this could be of use to you, then you can download the distribution files from our tools page. This project has been tested to work with JForum 2.1.8 running on Tomcat 6 and is built using Maven. The source code is included in the distribution and is released using the same BSD license as JForum. If you’d like to add any functionality, I’ll be happy to include it in a future release.

Now I’ve got to admit to being a big fan of IDEA. I’ve been using it for years now, and as the IntelliJ people have been saying all along: “it’s the best Java IDE that money can buy“. Well now it looks like it may well be the best free Java IDE too!

If you’ve not tried it, then now might be the perfect time to download it and give it a go. I can guarantee that after you’ve invested a little effort in figuring out what it can do for you, your productivity will increase dramatically. And that’s what’s always been key for me: if the time I save using the tool costs me less than the license fee, then it’s a no-brainer: pay up and work more efficiently. It’s  a simple value-for-money decision.

So what can it do? Well, for example, can your IDE attach to your database, load the schema and then give you code completion in the SQL strings that you write when programming JDBC? Work with Hibernate instead? Then maybe you’d appreciate the code completion for your HQL queries and also in  your mapping files. Want a UML diagram generated from your source code? No problem. If you’re a fan of Spring, then you might like the graphical view of the dependencies in a Spring application context? Need to see if your Spring pointcut syntax is right? Then a keyboard shortcut to view the advised methods on your beans will help with that. I could go on and on, but you probably get the idea.

Now this is where things get a little complicated. The JavaEE and framework features I’ve listed above won’t be available in the open-source, or “community”, edition. The JavaEE support is reserved for those that are still prepared to pay for it. Fair enough you might say; if you want better JavaEE support in Eclipse you’ll likely choose to use MyEclipse which currently costs over $150 and offers some of the best support available for Web development in that IDE. And I’d have to agree with  you: you pays your money, you takes your choice.

Regardless of this, the features available in the community edition of IDEA still far exceed those available in most other free Java IDEs and, in my opinion, are more reliable and robust oot. IDEA not only provides Java coding support but also XML, Groovy and regular expression syntax too. Add to this Live Templates (a build in macro language for automating common code generation, like iteration over collections/arrays for example)  and you’ve got a feature set that will keep most Java developers very happy. For a complete comparison matrix of the features that are available in the community and the ultimate editions, take a look at this link.

This seems to me to be a very clever marketing decision by IntelliJ. They are clearly aware that their greatest barrier to mass adoption is not the quality of the IDE, but the price of a license, and that by releasing this edition of their application they have completely eliminated this.

Good move I say, and good luck.