GWT & Spring Security

Sorry this is going to be a quick post without too much detail. But hopefully this will help someone out anyways until I can get to adding detail.

I've been struggling with how to integrate spring security with GWT. I don't have very much experience with using spring security and have been going in circles. After adding spring security with two additional files to configure it, I was able to show a login page and authenticate the user. However, as soon as that happened, the application failed to load because GWT uses POST requests to access the RPC. As it turns out, this isn't a sign that the configuration failed. Spring security expects a CSRF token on post requests to prevent security problems ... GWT doesn't insert this token when accessing the RPC... and so we get a forbidden error. Disabling csrf in the config for spring security is also not working.

I next tried using GWT's XSRF protection ... again I'm not very familiar with web application security. I thought if I did this, then my application would be able to tell spring security the csrf that it expects. This turned into a frustrating chicken and egg issue. To get the XSRF token, gwt does a POST request ... which is blocked by spring security.

Spring security examples that I've found have been for standard web applications, as opposed to GWT's host page mechanism.

I think the final solution is going to be:

1. Use spring security as a gate keeper to the application
1. Spring security needs to be configured to override a bunch of things, along the lines of https://crazygui.wordpress.com/2014/08/29/secure-rest-services-using-spring-security/
2. After authenticated, the application is responsible for maintaining security within itself
1. We can use the XSRF here for additional security
2. maintain session information for the authenticated user

So why even use spring security and not just wire up my own login screen etc? Spring security I think will be more flexible and give more options later down the road.

GWT 2.7.0 and Java 1.8

Well hello there, here's a quick post before I forget of some aggravating "errors" I encountered while trying to compile my code. We currently use GWT 2.7.0 and just upped our code to finally (stop laughing) use Java 1.8. Sounds great right?

Now, to be fair, I'm sure GWT mentions these issues in their documentation... but I'm also sure most of you haven't read through every iota of documentation and probably missed these awesome warnings.

The current warning I get when I compile my GWT module is:

[INFO] Tracing compile failure path for type 'org.eaglei.ui.gwt.search.SearchApplication'
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplication.java'
[INFO] [ERROR] org.eaglei.ui.gwt.uiconfig.rpc.SearchUIConfigServiceRemoteAsync cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/common/SearchTopPanel.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.common.SearchBarWidget cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplicationController.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.SearchApplicationContext cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-ui-gwt/4.5.0-SNAPSHOT/eagle-i-common-ui-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/uiconfig/rpc/SearchUIConfigServiceRemoteAsync.java'
[INFO] [ERROR] org.eaglei.services.uiconfig.SearchUIConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/common/SearchBarWidget.java'
[INFO] [ERROR] org.eaglei.ui.gwt.search.SearchApplicationContext cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-search-gwt/4.5.0-SNAPSHOT/eagle-i-search-gwt-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/ui/gwt/search/SearchApplicationContext.java'
[INFO] [ERROR] org.eaglei.services.uiconfig.SearchUIConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-services/4.5.0-SNAPSHOT/eagle-i-common-services-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/services/uiconfig/SearchUIConfig.java'
[INFO] [ERROR] org.eaglei.common.util.nodeinfo.NodeConfig cannot be resolved to a type
[INFO] [ERROR] Errors in 'jar:file:/Users/sophia/.m2/repository/org/eagle-i/eagle-i-common-util/4.5.0-SNAPSHOT/eagle-i-common-util-4.5.0-SNAPSHOT-sources.jar!/org/eaglei/common/util/nodeinfo/NodeConfig.java'
[INFO] [ERROR] Line 308: Type mismatch: cannot convert from List to List

So what the crap? I tried googling that last bit about List and only got results about people failing to use generics correctly. That's not my issue, I'm not using generics in this particular block of code.

It turns out it is because of a Java 1.8 enhancement I was using. Instead of:

List thingList = new ArrayList();

You can now omit the second type specifier:

List thingList = new ArrayList<>();

Fantastic!

Except if you use it in one of those fancy schmancy one line tertiary statements. In my code, the offending line of code was:

final List otherInstitutions = (other.getInstitutions() != null) ? other.getInstitutions() : new ArrayList<>();

By specifying the type in the tertiary statement, all was good:

final List otherInstitutions = (other.getInstitutions() != null) ? other.getInstitutions() : new ArrayList();

Yay?

Debugging GWT using eclipse and tomcat

Everything I've heard and read online indicated that setting up my eclipse to debug the client side portions of a GWT app is super easy ... so of course I end up flailing around helplessly into the wee hours trying to debug a supposedly simple client side bug.  My process up to this point has been to insert a crazy amount of ridiculous log statements into the code, compile, deploy, repeat.  I know that this is messy and sloppy, but I was adamantly against using the GWT debugger because of a prior attempt to get it going a year and half ago that turned into a huge time-suck and frustrations.  After having spent an exceedingly long night trying to debug something a few months ago that ended up taking as long as it did because of the multiple repetitions of inserting log statements, compile, deploy, repeat, I conceded that I had to get the GWT debugger working.

First off, I am deploying the application in a local tomcat, so I need to be able to debug what eclipse considers an external server ( as opposed to having eclipse / gwt spin up a server within eclipse ).  A quick google search for the keywords of interest brings up as the first result a very helpful stackoverflow answer:

1. Get google plugin for eclipse
2. The in eclipse, right click on your project and choose Debug as -> Web Application (running on external server)
3. Enter URL of your web app on tomcat (like http://localhost:8080/YourApp/YourApp.html and eclipse will give you new one - it will add stuff like ?gwt.codesvr=127.0.0.1:9997

Simple, right?  Sadly step 2 did nothing for me.  I select it, and nothing happens.  So what I ended up doing was to set up my own debug configurations.  When I did this, I kept getting this annoying error:

Working directory does not exist: /Users/myStuff/Documents/workspace/myProject-TRUNK/webapp/helloWorld/target/helloWorld-webapp-1.7-MS2.01-SNAPSHOT

I thought that perhaps this may have been related to the fact that we use maven and maybe that was throwing another complication into the mix.  As it turns out, if you don't provide a location of the deployed war to the configurations, GWT tries to access what it thinks the location.  The directory does in fact not exist, nor is it where my deployed war lives.  After some random clicking around and setting the directory to different places that may make sense, I figured out what it was looking for.  So, in summary, this is another way to get the GWT debugger to work by manually configuring things:

1. In eclipse, right click on your project and choose Debug as -> Debug Configurations ...
2. In the left hand panel, scroll down to "Web Application", select it and then click new.
   
3. Click on the New_configuration to edit it
4. In the Main tab, change the name of the configuration to something meaningful to you so you know what this configuration is for.  The project should be pre-filled with the name of the GWT app that you right clicked over. If it isn't, or it is not correct, click on the browse button to select the project.  This was a slight point of confusion for me, what project should I use? The code base I work on is very large with many modules. I chose the entry point into the application for the client as the GWT project ( and I chose correctly it seems ). I didn't know what main class to use or read up on what my options were, so I just left the default value.
   
5. Now go to the Server tab.  Because I am running tomcat locally on my machine, I do not want to use the embedded server, so uncheck this option.
   
6. Now go to the GWT tab.  Type in the name of the URL you would use in a browser to access your application. If you don't see the URL field, you probably forgot to uncheck the use embedded server in the previous step.  In my case, my application is running on https and the url needs to reflect this.  Additionally, note that the class that has your entry point should show up here.
   
7. Now go to the Arguments tab.  Here's where I ended up flailing for a bit.  At the beginning of the program arguments, add the following:
   -war /opt/tomcat6/webapps/helloWorld/
   You should use the fully qualified path to the your deployed application folder (not the *.war file)
   
   
8. Finally, you should probably add all the source for your project if you want to step through the debugger to the Source tab.

And that's it!  When you click on debug, you should see a tab on your screen where your console is that says "Development Mode".  One other probably obvious thing is that you want to start up tomcat first before clicking debug.  After this, you'll see in the Development Mode console a URL you can copy and paste into a browser and use for debugging the client side.

Yes, I know, this should be simple and straight forward, but I figured if I was having trouble ... I'm sure (hopefully) someone out there on the interwebs is having similar troubles.