I’m blogging about it at that address. The project is hosted on Github. I hope you’ll check it out, provide some feedback and maybe even get involved.

Fuzed Forums is, as you may know, a GWT site.  There are some special things that must be done in order for the Googlebot to understand a site rendered with AJAX.

Then the search itself must be integrated into the site.  I didn’t want to compromise the integrity of the GWT interface by using a separate traditional HTML page, so there were some tricks I had to figure out to make that happen (maybe I’ll blog about that soon, but some Googling of your own would probably reveal a path).

In any case, it’s good to have it working.

We have plenty of computers at my house, so sharing Chrome with others is not an issue for me.  However, I do have several Google accounts: personal, business, project … and Google helps by allowing me to be signed in to several at once, and allowing me to switch between them.  However, it’s not perfect.  There are still times where I need to sign out of other accounts so Google can figure out which account I want to use to access a particular service.

Having multiple users in Chrome allows me to target a browser window to a particular account, without confusion.  Chrome even shows a small icon at the top right of the window so you can quickly see “who you are”.

Good stuff so thanks to the Google Chrome team!

Fuzed Forums is developed on Google’s App Engine.  GAE offers most of the features developers are used to, starting with a servlet environment, a datastore, security mechanisms and more.

For Fuzed Forums, however, some of these out-of-the-box features weren’t quite enough.  I couldn’t simply authenticate users, for example.  A user authenticated for one forum is not necessarily authenticated for any other forum.  On the other hand, they may be authenticated for more than one forum at once.  That functionality required a bit of customization of the security features offered by Apache Shiro, which Fuzed Forums uses for  authentication and authorization.

There were other items like this, including working around the limitations of GAE’s SSL support, managing the context of a request, wiring together various third-party libraries … it’s a lot.

This makes we wonder if I did something wrong with my approach to Fuzed Forums.  Realistically, I almost certainly did.  However, I think it’s also true that much of the easy software has been done and most interesting things require working around the typical usage patterns of various software components (unless you have a really clever idea of course).

Fuzed Forums is now in “demo” mode.  This means it’s up and working and you can try it out.  But I want your feedback to incorporate it before it is released for your production use.  It also means that the data you create won’t survive after demo mode.  So take that as an invitation and a warning.

An easy way to try out Fuzed Forums is to visit the support forum.  Like the rest of this “demo”, this version of the support forum will not survive when Fuzed Forums moves out of demo, but you can get the feel of Fuzed Forums and provide feedback to make Fuzed Forums more of what you want for your community.  Also within the support forum is an area to provide feedback, proposing features or changes, whatever would like to see become part of Fuzed Forums.

If you want to try it out with a bit more content, visit The One Forum, which is filled with generated content.

If you want to find out where it’s going, more about the current limitations and more, see the “path” here.  You’ll notice that some things aren’t quite “done”, but I wanted to get this demo in front of people sooner rather than later.

Try it out and let me know what you think!

Products like vBulletin get the job done, but are hardly modern with their clunky web 1.0 interfaces. It’s also relatively expensive and complicated to get going with vBulletin, with the cost of the software, getting it hosted, installed and setup the way you want. That can easily run you over $200 a year, even for a small forum with a few users. However, you can customize vBulletin as much as you like, as long as you are willing to maintain those customizations, which is not for the casual forum administrator.

Other online solutions have made the setup easy. But their forum software is terrible. You can’t create a community there. You’re just one forum among the many. No since of membership or differentiation. And you’re usually stuck with their colors and layout.

It’s time forums moved into the modern era.

The idea is to follow the Validation sample that comes with the GWT 2.4 distribution.  The key items follow.

Inherit the Hibernate Validator

You need this in your gwt.xml file:

  <entry-point class='com.google.gwt.sample.validation.client.Validation' />

Setup the Validation Factory

Also in your gwt.xml, you need:

  <replace-with
    class="com.google.gwt.sample.validation.client.SampleValidatorFactory">
    <when-type-is class="javax.validation.ValidatorFactory" />
  </replace-with>

This is the factory that’s used when you build the validator.

Something else in that file is the code for setting up your messages. That’s optional: you can also specify your messages in your validation annotations. Refer to the Bean Validation documentation on what you should do in your case.

Setup for Deployment

You need the two validation-related libraries in your WEB-INF/lib directory:

• validation-api-1.0.0.GA.jar
• hibernate-validator-4.1.0.Final.jar

Then in your compile path, you need the two sources libraries:

• validation-api-1.0.0.GA-sources.jar
• hibernate-validator-4.1.0.Final-sources.jar

You can also put these in your WEB-INF/lib directory, but they’re not needed at runtime, only during the GWT compile phase.  This could be important if you’re using Google App Engine, where every added JAR lengthens your startup time.

Give it a Go

The rest is just applying the proper annotations and running the validator on your objects.  See the ValidationView.java file in the sample application for an example of this.  There are classes annotated with the validations from the framework in the shared sub-directory of the sample application.

GIN

I use Google GIN in my GWT application.  I currently don’t know the best “GIN way” to setup the validations.  I just have GIN create my validator instead of doing it in my code:

    @Provides
    @Singleton
    Validator createValidator() {
        return Validation.buildDefaultValidatorFactory().getValidator();
    }

I imagine there’s a better way, one that would replace the replace-with facility in the gwt.xml, but I don’t know what that is yet.

Feedback

I haven’t found good documentation on setting this up.  This post shows what works for me.  But it certainly may not be the best way to set things up.  If you have better information, please let me know.  I appreciate your feedback.

Getting Started

If you want to setup Shiro with Guice, you’ll need Shiro (I’m using 1.1.0) and Guice (I’m using 3.0).  Also, this post just tells you how to get started.  You should read all of the Shiro Reference Manual so you can apply Shiro appropriately to your situation.  Only then can you have confidence your app is secure.

As always, your feedback is appreciated.  If I’m doing something wrong, please let me know!

Shiro Realm

To adapt Shiro to your application, the first thing you need is to implement a “realm”.  The realm is the core adaptation mechanism between Shiro and your particular datasource (where  you store your authentication and authorization information).  This is a straightforward process: just follow the documentation, perhaps extending AuthorizingRealm, which is the logical extension point if you’re providing authentication and authorization context.  You might consider using SimpleAuthorizationInfo and SimpleAccount if you just need basic authentication and authorization in your realm.

The following is a simple realm example. The reference manual has information on writing a better realm than what you see here.  For example, you may want to use a HashedCredentialsMatcher instead of just matching clear character arrays.

public class MyRealm extends AuthorizingRealm {

    private static Logger logger = Logger.getLogger(MyRealm.class.getName());

    private MySecurityManagerService mySecurityManagerService;

    @Inject
    public MyRealm(MySecurityManagerService mySecurityManagerService) {
        // This is the thing that knows how to find user creds and roles
        this.mySecurityManagerService = mySecurityManagerService;
    }

    @Override
    protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principalCollection) {

        String username = (String) principalCollection.getPrimaryPrincipal();

        // Find the thing that stores your user's roles.
        MyPrincipal principal = mySecurityManagerService.findMyPrincipalByUsername(username);
        if (principal == null) {
            if (logger.isLoggable(Level.FINE)) {
                logger.fine("Principal not found for authorizing user with username: " + username);
            }
            return null;
        } else {
            if (logger.isLoggable(Level.FINE)) {
                logger.fine(String.format("Authoriziong user %s with roles: %s", username, principal.getRoles()));
            }
            SimpleAuthorizationInfo result = new SimpleAuthorizationInfo(principal.getRoles());
            return result;
        }
    }

    @Override
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken authenticationToken)
            throws AuthenticationException {

        UsernamePasswordToken usernamePasswordToken = (UsernamePasswordToken) authenticationToken;
        if (usernamePasswordToken.getUsername() == null || usernamePasswordToken.getUsername().isEmpty()) {
            throw new AuthenticationException("Authentication failed");
        }

        // Find the thing that stores your user's credentials.  This may be the same or different than
        // the thing that stores the roles.
        MyPrincipal principal = mySecurityManagerService.findMyPrincipalByUsername(usernamePasswordToken.getUsername());
        if (principal == null) {
            if (logger.isLoggable(Level.FINE)) {
                logger.fine("Principal not found for user with username: " + usernamePasswordToken.getUsername());
            }
            return null;
        }

        if (logger.isLoggable(Level.FINE)) {
            logger.fine("Principal found for authenticating user with username: " + usernamePasswordToken.getUsername());
        }

        return new SimpleAccount(principal.getUsername(), principal.getPassword(), getName(),
                principal.getRoles(), new HashSet());
    }
}

That should get you started anyway.

Shiro Filter

Shiro has something of it’s own mini dependency injection facility with the IniShiroFilter.  There is good documentation on that, and I think it might be the default configuration facility for most people using Shiro.  However, if you’re using Guice, that’s not the way you want to go.  You want to leverage Guice to wire everything together, and just do in Shiro what Shiro is meant for: security.

So you need another, more basic, filter.  Shiro could have just provided such a basic, essential module.  But they don’t.  I don’t know why.  Nevertheless, it’s easy to make your own.  Really easy.  Prepare yourself.  Here it is:

@Singleton
public class ShiroFilter extends AbstractShiroFilter {

	@Inject
	public ShiroFilter(WebSecurityManager webSecurityManager) {
		setSecurityManager(webSecurityManager);
	}
}

Once you have your mind around that, you’ll need to do yourself some AOP.

Guice Interceptor

Shiro uses AOP to intercept method invocations for access control. Generally, that’s what you want: it’s non-intrusive and extensible. But it doesn’t use standard APIs to do that. I don’t know why. Guice, on the other hand, uses the AOP Alliance API for interception. So you need to make the one fit into the other.

The APIs are very similar, though (again, why not just use the AOP Alliance APIs? …), so it’s easy to adapt them:

public class ShiroMethodInterceptor implements MethodInterceptor {

	private RoleAnnotationMethodInterceptor roleAnnotationMethodInterceptor = new RoleAnnotationMethodInterceptor();

	@Override
	public Object invoke(MethodInvocation methodInvocation) throws Throwable {
		return roleAnnotationMethodInterceptor.invoke(new ShiroMethodInvocation(methodInvocation));
	}

	private static class ShiroMethodInvocation implements org.apache.shiro.aop.MethodInvocation {

		private MethodInvocation methodInvocation;

		public ShiroMethodInvocation(MethodInvocation methodInvocation) {
			this.methodInvocation = methodInvocation;
		}
...

Easy stuff, right?

Wiring it All Together

Shiro is very modular.  And if you’re using the default configuration, they really take care of things for you.  But who does that?  Not me.  So that means you need to assemble the parts you need for your particular environment.  This includes:

• Creating a Realm for your particular environment
• Selecting a session manager
• Selecting a remember-me manager
• Selecting a SecurityManager and telling it about your realm, session manager and remember-me manager

You should know what all of those things are because you should have read the Shiro documentation, which is not bad at all.  I created a custom realm and then did the following inside one of my Guice modules:

public class MyModule extends AbstractModule {

	@Override
	protected void configure() {
		...
		bind(Realm.class).to(MyRealm.class);
		bindInterceptor(Matchers.any(), Matchers.annotatedWith(RequiresRoles.class),
		        new ShiroMethodInterceptor());
	}

	@Provides
	@Singleton
	WebSecurityManager provideSecurityManager(Realm realm, SessionManager sessionManager, RememberMeManager rememberMeManager) {
		DefaultWebSecurityManager result = new DefaultWebSecurityManager(realm);
		result.setSessionManager(sessionManager);
		result.setRememberMeManager(rememberMeManager);
		return result;
	}

	@Provides
	@Singleton
	SessionManager provideSessionManager() {
	    return new ServletContainerSessionManager();
	}

	@Provides
	@Singleton
	RememberMeManager provideRememberMeManager() {
	    return new CookieRememberMeManager();
	}
}

I love how easy it is to do AOP in Guice.  So nice.

In Google App Engine, it’s important to use the ServletContainerSessionManager instead of something like DefaultWebSessionManager because the latter tries to start threads, which GAE doesn’t care for at all.

The last thing you need to wire in is that filter, so Shiro will actually get involved in your web requests.  I again do that with Guice:

public class MyServletModule extends ServletModule {

	@Override
	protected void configureServlets() {
		filter("/*").through(ShiroFilter.class);
	}
}

To make that work, you need to have configured Guice in your web.xml.

Securing Services

Authentication with Shiro is nice and simple.  The 10 Minute Tutorial will get you started. In the simplest case might do something like this:

        Subject subject = SecurityUtils.getSubject();
        UsernamePasswordToken token = new UsernamePasswordToken(username, password);
        token.setRememberMe(true);
        try {
            subject.login(token);
        } catch (AuthenticationException ae) {
            // handle failed logins here ... see the docs for more exceptions
        }

Authorization is even easier.  If you’re doing something basic, you will probably want some role-based security on your services. Shiro provides nice APIs for checking roles and permissions. I currently only care about roles. And that’s why we setup that aspect. To add role access control to your service method (on the server side of course!), just do something like this:

    @RequiresRoles("importantRole")
    public void doSomethingImportant(...) {
    ...

I’m confident most everyone reading this knows that checking permissions on the client in a web app is not enough. So you need to do your security on the server side. Once something is on the client computer all bets are off!

In my app, I return some data useful for predicating particular permissions so I can toggle buttons, show panels, etc, on the client. But I do all of that an more on the server.

Conclusion

I think Apache Shiro is a good choice for adding security to a Guice-based app.  In particular it’s working well for me in Google App Engine with a GWT front-end.  I hope this guide helps some if you’re working a similar environment.  As always, if you see something I’m doing wrong, let me know!

Add the JAR

You’ll need to add guice-persist.jar to your classpath.  It’s part of the Guice 3.0 distribution.

Get the Source

The source for all of Google Guice is available here.  You’ll specifically want the items in the package com.google.inject.persist.jpain the extensions module. Copy that somewhere into your work area, renaming the package as appropriate.  You’ll have a lot of compile errors, but that’s to be expected.

Replace JPA Stuff with JDO Stuff

Now you need to start hacking.

JDO uses PersistenceManager where JPA uses EntityManager.  So first replace occurrences EntityManager with PersistenceManager.

Next, replace occurrences of “Jpa” with “Jdo” and “jpa” with “jdo”.

We have a slightly different syntax for getting the current transaction.  Replace:

EntityTransaction txn = em.getTransaction();

with

Transaction txn = pm.currentTransaction();

The source uses the @Nullable annotation, which is internal to the Guice package. So I just removed it. The same goes for the Preconditions and Lists utilities: remove the former and use new ArrayList<Class<?>>() for the latter.

One Minor Improvement

Okay, maybe this is a major improvement.  But there’s a limitation in the way the injected PersistenceManager instance works: if your injected objects happen to be singletons (not created with each request), then you need to inject a Provider<PersistenceManager> instance instead.  I work in a web environment, and, since everything starts with a servlet, inevitably, things end up effectively being singletons.  (However, if I’m just missing something important, please let me know.  I’m still rather new to Guice).

So, if you don’t want to use providers, but still want Guice Persist to effectively manage transactions, use this trick.  In what becomes the JdoPersistService, make your get method look like this:

    @Override
    public PersistenceManager get() {
        return (PersistenceManager) Proxy.newProxyInstance(PersistenceManager.class.getClassLoader(),
                new Class[] { PersistenceManager.class }, new InvocationHandler() {

                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        if (!isWorking()) {
                            begin();
                        }

                        PersistenceManager pm = persistenceManager.get();

                        return method.invoke(pm, args);
                    }
                });
    }

With that small change, the injected persistence manager will never be “old”, but work in the context of a transaction no matter if it’s injected into a singleton or a new instances.

I think that’s about it.  If I’m missed a change, let me know and I’ll tell you what I did.  If I missed something fundamental, let me know so I can fix it in my code!

The tutorial states:

Experienced GWT users will notice the similarity to the way GWT image bundles and messages are done: You simply create a method for each object type you want to create, and the an implementation of the interface gets generated for you at compile time.

Note that you only need to create injector methods for classes that you would directly access in your top-level initialization code, such as the UI classes to install in your RootPanel. You don’t need to create injector methods for lower-level classes that will be automatically injected. So for example, if Class A uses class B which uses class C, you only need to create an injector method for A, as the other classes B and C will automatically be injected into A.

In other words, injector methods provide a bridge between the Guice and non-Guice world.

I still find that explanation confusing.  But I finally realized they’re trying to say that you only create methods for getting an object from the injector:

MyClass myObject = injector.getMyClass();

That’s it.  So where in Guice you would do this:

MyClass myObject = injector.getInstance(MyClass.class);

In Gin you do this:

MyClass myObject = injector.getMyClass();

So if you need to call a method on the injector, create it. I ended up with one method.