The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
Yesterday, Abbie and Jack showed you how to be a superhero. Today they're back with an action-packed video titled Upside Down Man Saves the Day. Watch it if you'd like to see how to take out a tiger, wrestle an alligator and diffuse a bomb. This short film was written, directed and filmed by Abbie, the only thing I did was add the music. Enjoy! 
If you have trouble viewing it here, check it out on YouTube.
For some reason, my kids are very interested in Super Heros lately. In fact, they know so much about them that they've decided to start teaching others how to become one. Checkout the videos we shot earlier today with their step-by-step instructions.
I hope Abbie and Jack's tips help you become a super hero! 
Yesterday, I delivered my Comparing Kick-Ass Web Frameworks talk at the Rich Web Experience in Orlando, Florida. Below are the slides I used:
Although it's difficult to convey a presentation in a slide deck, I can offer you my conclusion: there is no "best" web framework. I believe web frameworks are like spaghetti sauce in that everyone has different tastes and having so many choices is necessary to satisfy everyone. You can read more about the plural nature of perfection in Malcolm Gladwell's The Ketchup Conundrum (a written version of What we can learn from spaghetti sauce). Even though there is no "best" web framework, I believe GWT, Flex, Rails and Grails are frameworks that every web developer should try. They really do make it fun to develop web applications.
You can find the slides for my other RWE talk at Building SOFEA Applications with GWT and Grails.
Kudos to Jay Zimmerman for putting on a great show in Orlando this year. I had a great time talking with folks and learning in the sessions I attended. I particularly enjoyed bringing my parents and kids and staying at such a nice resort. Disney World (Magic Kingdom) and Universal Studios was very enjoyable due to the short lines. Also, the weather was perfect - especially considering the freezing cold in Denver this week.
A couple of weeks ago, I wrote about how I improved this site's YSlow grade by concatenating JavaScript and CSS with wro4j. Even though I loved the improvements, there was still work to do:
I'm now sitting at a YSlow (V2) score of 75; 90 if I use the "Small Site or Blog" ruleset. I believe I can improve this by adding expires headers to my images, js and css.
Last Monday, wro4j 1.1.0 was released and I thought it would solve my last remaining issue. Unfortunately, it only adds expires headers (and ETags) to images referenced in included CSS. Of course, this makes sense, but I thought they'd add a filter to explicitly add expires headers.
Since I still wanted this feature, I did some searching around and found what I was looking for: OSCache's CacheFilter. It was surprisingly easy to setup, I downloaded OSCache 2.4.1, added it to my WEB-INF/lib directory, and added the following to my web.xml.
<filter>
<filter-name>CacheFilter</filter-name>
<filter-class>com.opensymphony.oscache.web.filter.CacheFilter</filter-class>
<init-param>
<param-name>expires</param-name>
<param-value>time</param-value>
</init-param>
<init-param>
<param-name>time</param-name>
<param-value>2592000</param-value> <!-- one month -->
</init-param>
<init-param>
<param-name>scope</param-name>
<param-value>session</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CacheFilter</filter-name>
<url-pattern>*.gif</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CacheFilter</filter-name>
<url-pattern>*.jpg</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CacheFilter</filter-name>
<url-pattern>*.png</url-pattern>
</filter-mapping>
After restarting Tomcat and clearing out my Firefox cache, I was in business.
I did experience one issue along the way when I tried to remove the oscache.jar from my WEB-INF/lib directory. I'm using the JSPWiki Plugin and it seems to rely on a class in oscache.jar. I'm not sure which version oscache.jar is, but the packages got moved around somewhere along the way. The good news is it seems OK to have both oscache.jar and oscache-2.4.1.jar in Roller's classpath.
After discovering the duplicate JARs issue, I got to thinkin' that EhCache would probably have a solution. Sure enough, it has a SimpleCachingHeadersPageCachingFilter. Since I already had a working solution, I didn't bother trying EhCache (especially since my Roller install uses EhCache 1.1 and the filter is only available in a later version). However, when I implement expires headers in AppFuse, I'll definitely try EhCache's solution.
As for my YSlow score, it didn't improve as much as I'd hoped (low 80s instead of mid 80s). Some of this is due to my embedded presentation from Slideshare. There's also some external images I'm using in my Lightbox JS implementation. So if I can find a better Lightbox implementation (supports rel="lightbox" syntax), there's a good chance I'll switch. In the meantime, I'm lovin' how much faster this site loads.
In case you're wondering, I do plan on adding css/js concatenation and expires headers to both AppFuse 2.1 and Roller 5.
Update: FWIW, I did try to configure expires headers in Apache, but the AJP 1.3 Connector doesn't seem to allow this to work. To quote Keith from KGB Internet:
I added an expires directive and it didn't touch the header for anything served from Tomcat, but does for content served directly by Apache. This might have to be set up in Tomcat.
Last night, I spoke at the Denver Java User Group meeting. The consulting panel with Matthew, Tim and Jim
a lot of fun and I enjoyed delivering my Building SOFEA Applications with GWT and Grails presentation for the first time. The talk was mostly a story about how we enhanced Evite.com with GWT and Grails and what we did to make both frameworks scale. I don't believe the presentation reflects the story format that well, but it's not about the presentation, it's about the delivery of it.
If you'd like to hear the story about this successful SOFEA implementation at a high-volume site, I'd recommend attending the Rich Web Experience next month. If you attended last night's meeting and have any feedback on how this talk can be improved, I'd love to hear it.
Earlier this week, Hiram Chirino released RestyGWT, a GWT generator for REST services and JSON encoded data transfer objects. You can read more about it in Hiram's post RestyGWT, a Better GWT RPC??. First of all, I'm impressed with RestyGWT because provides something I've always wanted with GWT: the ability to call RESTful services and get a populated POJO in your callback, much like AsyncCallback provides for RPC services.
RestyGWT also allows you to easily create services using only interfaces and JAX-RS annotations. For example:
import javax.ws.rs.POST;
...
public interface PizzaService extends RestService {
@POST
public void order(PizzaOrder request, MethodCallback<OrderConfirmation> callback);
}
After taking a brief look at RestyGWT, I thought it'd be interesting to share how I develop and test GWT client services.
Developing GWT Client Services
Writing services in a GWT application can be helpful when you're using MVP, especially since you can EasyMock them in a test. On my GWT projects, I've often used overlay types because they allow me to write less code and they make parsing JSON super simple.
I've had issues testing my presenters when using overlay types. The good news is I think I've figured out a reasonable solution, but it does require using GWTTestCase. If RestyGWT supported overlay types, there's a good chance I'd use it, especially since its integration tests seem to require GWTTestCase too.
Rather than using callbacks in my presenters, I try to only use them in my service implementations. That way, my presenters don't have to worry about overlay types and can be tested in a JUnit-only fashion. The callbacks in my services handle JSON parsing/object population and fire events with the populated objects.
GWT's RequestBuilder is one option for communicating with RESTful services. The Development Guide for HTTP Requests explains how to use this class. To simplify REST requests and allow multiple callbacks, I'm using a RestRequest class, and a number of other utility classes that make up a small GWT REST framework (created by a former colleague). RestRequest wraps RequestBuilder and provides a Fluent API for executing HTTP requests. Another class, Deferred, is a GWT implementation of Twisted's Deferred.
As part of my service implementation, I inject an EventBus (with GIN) into the constructor and then proceed to implement callbacks that fire Events to indicate loading, saving and deleting has succeeded. Here's an example service:
public class ConversationServiceImpl implements ConversationService {
private EventBus eventBus;
@Inject
public ConversationServiceImpl(EventBus eventBus) {
this.eventBus = eventBus;
}
public void getConversation(String name) {
Deferred<Representation> d =
RestRequest.get(URLs.CONVERSATION + "/" + URL.encode(name)).build();
d.addCallback(new Callback<Representation>() {
public void onSuccess(Representation result) {
Conversation conversation = convertResultToConversation(result);
eventBus.fireEvent(new ResourceLoadedEvent<Conversation>(conversation));
}
});
d.run();
}
public void saveConversation(Conversation conversation) {
Deferred<Representation> d = RestRequest.post(URLs.CONVERSATION)
.setRequestData(conversation.toJson()).build();
d.addCallback(new Callback<Representation>() {
public void onSuccess(Representation result) {
Conversation conversation = convertResultToConversation(result);
eventBus.fireEvent(new ResourceSavedEvent<Conversation>(conversation));
}
});
d.run();
}
public void deleteConversation(Long id) {
Deferred<Representation> d =
RestRequest.post(URLs.CONVERSATION + "/" + id).build();
d.addCallback(new Callback<Representation>() {
public void onSuccess(Representation result) {
eventBus.fireEvent(new ResourceDeletedEvent());
}
});
d.run();
}
/**
* Convenience method to populate object in one location
*
* @param result the result of a resource request.
* @return the populated object.
*/
private Conversation convertResultToConversation(Representation result) {
JSOModel model = JSOModel.fromJson(result.getData());
return new Conversation(model);
}
}
In the saveConversation() method you'll notice the conversation.toJson() method call. This method uses a JSON class that loops through an objects properties and constructs a JSON String.
public JSON toJson() {
return new JSON(getMap());
}
Testing Services
In my experience, the hardest part about using overlay types is writing your objects so they get populated correctly. I've found that writing tests which read JSON from a file can be a great productivity boost. However, because of overlay types, you have to write a test that extends GWTTestCase. When using GWTTestCase, you can't simply read from the filesystem. The good news is there is a workaround where you can subclass GWTShellServlet and overwrite GWT's web.xml to have your own servlet that can read from the filesystem. A detailed explanation of how to do this was written by Alex Moffat in Implementing a -noserver flag for GWTTestCase.
Once this class is in place, I've found you can easily write services using TDD and the server doesn't even have to exist. When constructing services, I've found the following workflow to be the most productive:
Below is the code for my JsonReaderServlet.java:
public class JsonReaderServlet extends GWTShellServlet {
public void service(ServletRequest servletRequest, ServletResponse servletResponse)
throws ServletException, IOException {
HttpServletRequest req = (HttpServletRequest) servletRequest;
HttpServletResponse resp = (HttpServletResponse) servletResponse;
String uri = req.getRequestURI();
if (req.getQueryString() != null) {
uri += "?" + req.getQueryString();
}
if (uri.contains("/services")) {
String method = req.getMethod();
String output;
if (method.equalsIgnoreCase("get")) {
// use the part after the last slash as the filename
String filename = uri.substring(uri.lastIndexOf("/") + 1, uri.length()) + ".json";
System.out.println("loading: " + filename);
String json = readFileAsString("/" + filename);
System.out.println("loaded json: " + json);
output = json;
} else {
// for posts, return the same body content
output = getBody(req);
}
PrintWriter out = resp.getWriter();
out.write(output);
out.close();
resp.setStatus(HttpServletResponse.SC_OK);
} else {
super.service(servletRequest, servletResponse);
}
}
private String readFileAsString(String filePath) throws IOException {
filePath = getClass().getResource(filePath).getFile();
BufferedReader reader = new BufferedReader(new FileReader(filePath));
return getStringFromReader(reader);
}
private String getBody(ServletRequest request) throws IOException {
BufferedReader reader = new BufferedReader(new InputStreamReader(request.getInputStream()));
return getStringFromReader(reader);
}
private String getStringFromReader(Reader reader) throws IOException {
StringBuilder sb = new StringBuilder();
char[] buf = new char[1024];
int numRead;
while ((numRead = reader.read(buf)) != -1) {
sb.append(buf, 0, numRead);
}
reader.close();
return sb.toString();
}
}
This servlet is mapped to <url-pattern>/*</url-pattern> in a web.xml file in src/test/resources/com/google/gwt/dev/etc/tomcat/webapps/ROOT/WEB-INF.
My Service Test starts by getting an EventBus from GIN and registering itself to handle the fired events.
public class ConversationServiceGwtTest extends AbstractGwtTestCase
implements ResourceLoadedEvent.Handler, ResourceSavedEvent.Handler, ResourceDeletedEvent.Handler {
ConversationService service;
ResourceLoadedEvent<Conversation> loadedEvent;
ResourceSavedEvent<Conversation> savedEvent;
ResourceDeletedEvent deletedEvent;
@Override
public void gwtSetUp() throws Exception {
super.gwtSetUp();
DesigntimeGinjector injector = GWT.create(MyGinjector.class);
EventBus eventBus = injector.getEventBus();
service = new ConversationServiceImpl(eventBus);
eventBus.addHandler(ResourceLoadedEvent.ENGINE, this);
eventBus.addHandler(ResourceSavedEvent.ENGINE, this);
eventBus.addHandler(ResourceDeletedEvent.ENGINE, this);
}
@SuppressWarnings("unchecked")
public void onLoad(ResourceLoadedEvent event) {
this.loadedEvent = event;
}
@SuppressWarnings("unchecked")
public void onSave(ResourceSavedEvent event) {
this.savedEvent = event;
}
public void onDelete(ResourceDeletedEvent event) {
this.deletedEvent = event;
}
}
After this groundwork has been done, a test can be written that loads up the JSON file and verifies the objects are populated correctly.
public void testGetConversation() {
service.getConversation("test-conversation");
Timer t = new Timer() {
public void run() {
assertNotNull("ResourceLoadedEvent not received", loadedEvent);
Conversation conversation = loadedEvent.getResource();
assertEquals("Conversation name is incorrect","Test Conversation", conversation.getName());
assertNotNull("Conversation has no channel", conversation.getChannel());
assertEquals("Conversation has incorrect task size", 3, conversation.getTasks().size());
convertToAndFromJson(conversation);
finishTest();
}
};
delayTestFinish(3000);
t.schedule(100);
}
private void convertToAndFromJson(Conversation fromJsonModel) {
Representation json = fromJsonModel.toJson();
assertNotNull("Cannot convert empty JSON", json.getData());
// change back into model
JSOModel data = JSOModel.fromJson(json.getData());
Conversation toJsonModel = new Conversation(data);
verifyModelBuiltCorrectly(toJsonModel);
}
private void verifyModelBuiltCorrectly(Conversation model) {
assertEquals("Conversation name is incorrect", "Test Conversation", model.getString("name"));
assertEquals("Conversation has incorrect task size", 3, model.getTasks().size());
assertEquals("Conversation channel is incorrect", "Web", model.getChannel().getString("type"));
}
For more information on the usage of the Timer, finishTest() and delayTestFinish(), see GWTTestCase's javadoc.
The tests for saving and deleting a resource look as follows:
public void testSaveConversation() {
Conversation conversation = new Conversation().setName("Test").setId("1");
List<Task> tasks = new ArrayList<Task>();
for (int i = 1; i < 4; i++) {
tasks.add(new Task().setName("Task " + i));
}
conversation.setTasks(tasks);
System.out.println("conversation.toJson(): " + conversation.toJson());
assertTrue(conversation.toJson().toString().contains("Task 1"));
service.saveConversation(conversation);
Timer t = new Timer() {
public void run() {
assertNotNull("ResourceSavedEvent not received", savedEvent);
finishTest();
}
};
delayTestFinish(3000);
t.schedule(100);
}
public void testDeleteConversation() {
service.deleteConversation(1L);
Timer t = new Timer() {
public void run() {
assertNotNull("ResourceDeletedEvent not received", deletedEvent);
finishTest();
}
};
delayTestFinish(3000);
t.schedule(100);
}
Summary
This article has shown you how I develop and test GWT Client Services. If RestyGWT supported overlay types, there's a good chance I could change my service implementation to use it and I wouldn't have to change my test. Robert Cooper, author of GWT in Practice, claims he has a framework that does this. Here's to hoping this article stimulates the GWT ecosystem and we get a GWT REST framework that's as easy to use as GWT RPC.
Update: Today I enhanced this code to use Generics-based classes (inspired by Don't repeat the DAO!) for the boiler-plate CRUD code in a service. In a nutshell, a service interface can now be written as:
public interface FooService extends GenericService<Foo, String> {
}
The implementation class is responsible for the URL and converting the JSON result to an object:
public class FooServiceImpl extends GenericServiceImpl<Foo, String> implements FooService {
@Inject
public FooServiceImpl(EventBus eventBus) {
super(eventBus, "/services/foo");
}
@Override
protected Foo convertResultToModel(Representation result) {
return new Foo(JSOModel.fromJson(result.getData()));
}
}
I'm sure this can be further enhanced to get rid of the need to create classes altogether, possibly leveraging GIN or some sort of factory. The parent classes referenced in this code can be viewed at the following URLs:
There's also a GenericServiceGwtTest.java that proves it all works as expected.
Yesterday, I wrote about How to do cross-domain GWT RPC with a ProxyServlet. Today I'll be discussing how to modify the ProxyServlet to authenticate with Spring Security. For the application I'm working on, the ProxyServlet is only used in development (when running GWT's hosted mode) and isn't necessary when deploying the client and server on the same server. Using the ProxyServlet allows cross-domain requests so you can run GWT in hosted mode and talk to your backend running on another server. This setup can be especially handy in that you can easily point your hosted client at different backends (for example, if you have testing and staging environments).
In this example, the backend application is a JSF/Spring application that has Spring Security wired in to protect services with both Basic and Form-based authentication. Basic authentication will kick in if a "Authorization" header is sent, otherwise Form-based authentication is used. Here's the Spring Security context file that makes this happen:
<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security"
xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="...">
<http auto-config="true" realm="My Web Application">
<intercept-url pattern="/faces/welcome.jspx" access="ROLE_USER"/>
<intercept-url pattern="/*.rpc" access="ROLE_USER"/>
<http-basic/>
<form-login login-page="/faces/login.jspx" authentication-failure-url="/faces/accessDenied.jspx"
login-processing-url="/j_spring_security_check" default-target-url="/redirect.jsp"
always-use-default-target="true"/>
</http>
<authentication-provider>
<user-service >
<user name="admin" password="admin" authorities="ROLE_USER"/>
</user-service>
</authentication-provider>
</beans:beans>
The easiest way to configure your GWT application to talk to a Spring Security protected resource is to protect your HTML page that GWT is embedded in. This is the documented way to integrate GWT with Spring Security (ref: GWT's LoginSecurityFAQ, search for "Acegi"). This works well for production, but not for hosted-mode development.
Basic Authentication
To authenticate with Basic Authentication, you can use GWT's RequestBuilder and set an "Authentication" header that
contains the user's (base64-encoded) credentials.
private class LoginRequest {
public LoginRequest(RequestCallback callback) {
String url = "/services/faces/welcome.jspx";
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, url);
rb.setHeader("Authorization", createBasicAuthToken());
rb.setCallback(callback);
try {
rb.send();
} catch (RequestException e) {
Window.alert(e.getMessage());
}
}
}
protected String createBasicAuthToken() {
byte[] bytes = stringToBytes(username.getValue() + ":" + password.getValue());
String token = Base64.encode(bytes);
return "Basic " + token;
}
protected byte[] stringToBytes(String msg) {
int len = msg.length();
byte[] bytes = new byte[len];
for (int i = 0; i < len; i++)
bytes[i] = (byte) (msg.charAt(i) & 0xff);
return bytes;
}
To use this LoginRequest class, create it with a callback and look for a 401 response code to determine if authentication failed.
new LoginRequest(new RequestCallback() {
public void onResponseReceived(Request request, Response response) {
if (response.getStatusCode() != Response.SC_UNAUTHORIZED &&
response.getStatusCode() != Response.SC_OK) {
onError(request, new RequestException(response.getStatusText() + ":\n" + response.getText()));
return;
}
if (response.getStatusCode() == Response.SC_UNAUTHORIZED) {
Window.alert("You have entered an incorrect username or password. Please try again.");
} else {
// authentication worked, show a fancy dashboard screen
}
}
public void onError(Request request, Throwable throwable) {
Window.alert(throwable.getMessage());
}
});
If your GWT application is included in the "services" war, everything should work at this point. However, if you try to login with invalid credentials, your browser's login dialog will appear. To suppress this in the aforementioned ProxyServlet, you'll need to make a change in its executeProxyRequest() method so the "WWW-Authenticate" header is not copied.
// Pass the response code back to the client
httpServletResponse.setStatus(intProxyResponseCode);
// Pass response headers back to the client
Header[] headerArrayResponse = httpMethodProxyRequest.getResponseHeaders();
for (Header header : headerArrayResponse) {
if (header.getName().equals("Transfer-Encoding") && header.getValue().equals("chunked") ||
header.getName().equals("Content-Encoding") && header.getValue().equals("gzip") ||
header.getName().equals("WWW-Authenticate")) { // don't copy WWW-Authenticate header
} else {
httpServletResponse.setHeader(header.getName(), header.getValue());
}
}
I'm not sure how to suppress the browser prompt when not using the ProxyServlet. If you have a solution, please let me know.
Basic Authentication works well for GWT applications because you don't need additional logic to retain the authenticated state after the initial login. While Basic Authentication over SSL might offer a decent solution, the downside is you can't logout. Form-based Authentication allows you to logout.
Form-based AuthenticationBefore I show you how to implement form-based authentication, you should be aware that Google does not recommend this. Below is a warning from their LoginSecurityFAQ.
Do NOT attempt to use the Cookie header to transfer the sessionID from GWT to the server; it is
fraught with security issues that will become clear in the rest of this article. You MUST transfer
the sessionID in the payload of the request. For an example of why this can fail, see CrossSiteRequestForgery.
In my experiment, I didn't want to change the server-side Spring Security configuration, so I ignored this warning. If you know how to configure Spring Security so it looks for the sessionID in the payload of the request (rather than in a cookie), I'd love to hear about it. The upside of the example below is it should work with container-managed authentication as well.
The LoginRequest class for form-based authentication is similar to the previous one, except it has a different URL and sends the user's credentials in the request body.
private class LoginRequest {
public LoginRequest(RequestCallback callback) {
String url = "/services/j_spring_security_check";
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, url);
rb.setHeader("Content-Type", "application/x-www-form-urlencoded");
rb.setRequestData("j_username=" + URL.encode(username.getValue()) +
"&j_password=" + URL.encode(password.getValue()));
rb.setCallback(callback);
try {
rb.send();
} catch (RequestException e) {
Window.alert(e.getMessage());
}
}
}
If you deploy your GWT application in the same WAR your services are hosted in, this is all you'll need to do. If you're using the ProxyServlet, there's a couple of changes you'll need to make in order to set/send cookies when running in hosted mode.
First of all, you'll need to make sure you've configured the servlet to follow redirects (by subclassing or simply modifying its default).
After that, add the following logic on line 358 (or just look for "if (followRedirects)") to expose the sessionID to the client. The most important part is setting the cookie's path to "/" so the client (running at localhost:8888) can see it.
if (followRedirects) {
// happens on first login attempt
if (stringLocation.contains("jsessionid")) {
Cookie cookie = new Cookie("JSESSIONID",
stringLocation.substring(stringLocation.indexOf("jsessionid=") + 11));
cookie.setPath("/");
httpServletResponse.addCookie(cookie);
// the following happens if you refresh your GWT app after already logging in once
} else if (httpMethodProxyRequest.getResponseHeader("Set-Cookie") != null) {
Header header = httpMethodProxyRequest.getResponseHeader("Set-Cookie");
String[] cookieDetails = header.getValue().split(";");
String[] nameValue = cookieDetails[0].split("=");
Cookie cookie = new Cookie(nameValue[0], nameValue[1]);
cookie.setPath("/");
httpServletResponse.addCookie(cookie);
}
httpServletResponse.sendRedirect(stringLocation.replace(getProxyHostAndPort() +
this.getProxyPath(), stringMyHostName));
return;
}
Click here to see a screenshot of the diff of the ProxyServlet after this code has been added.
Figuring out that headers needed to be parsed after authenticating successfully and before redirecting was the hardest part for me. If you grab the JSESSIONID from the "Set-Cookie" header anywhere else, the JSESSIONID is one that hasn't been authenticated. While the login will work, subsequent calls to services will fail.
To make subsequent calls with the cookie in the header, you'll need to make an additional modification to ProxyServlet to send cookies as headers. First of all, add a setProxyRequestCookies() method:
/**
* Retrieves all of the cookies from the servlet request and sets them on
* the proxy request
*
* @param httpServletRequest The request object representing the client's
* request to the servlet engine
* @param httpMethodProxyRequest The request that we are about to send to
* the proxy host
*/
@SuppressWarnings("unchecked")
private void setProxyRequestCookies(HttpServletRequest httpServletRequest,
HttpMethod httpMethodProxyRequest) {
// Get an array of all of all the cookies sent by the client
Cookie[] cookies = httpServletRequest.getCookies();
if (cookies == null) {
return;
}
for (Cookie cookie : cookies) {
cookie.setDomain(stringProxyHost);
cookie.setPath(httpServletRequest.getServletPath());
httpMethodProxyRequest.setRequestHeader("Cookie", cookie.getName() +
"=" + cookie.getValue() + "; Path=" + cookie.getPath());
}
}
Next, in the doGet() and doPost() methods, add the following line just after the call to setProxyRequestHeaders().
setProxyRequestCookies(httpServletRequest, getMethodProxyRequest);
After making these modifications to ProxyServlet, you can create LoginRequest and attempt to authenticate. To detect a failed attempt, I'm looking for text in Spring Security's "authentication-failure-url" page.
new LoginRequest(new RequestCallback() {
public void onResponseReceived(Request request, Response response) {
if (response.getStatusCode() != Response.SC_OK) {
onError(request, new RequestException(response.getStatusText() + ":\n" + response.getText()));
return;
}
if (response.getText().contains("Access Denied")) {
Window.alert("You have entered an incorrect username or password. Please try again.");
} else {
// authentication worked, show a fancy dashboard screen
}
}
public void onError(Request request, Throwable throwable) {
Window.alert(throwable.getMessage());
}
});
After making these changes, you should be able to authenticate with Spring Security's form-based configuration. While this example doesn't show how to logout, it should be easy enough to do by 1) deleting the JSESSIONID cookie or 2) calling the Logout URL you have configured in your services WAR.
Hopefully this howto gives you enough information to configure your GWT application to talk to Spring Security without modifying your existing backend application. It's entirely possible that Spring Security offers a more GWT-friendly authentication mechanism. If you know of a better way to integrate GWT with Spring Security, I'd love to hear about it.
Update on October 7, 2009: I did some additional work on this and got Remember Me working when using form-based authentication. I found I didn't need as much fancy logic in my ProxyServlet and was able to reduce the "followRequests" logic to the following:
if (followRedirects) {
if (httpMethodProxyRequest.getResponseHeader("Set-Cookie") != null) {
Header[] headers = httpMethodProxyRequest.getResponseHeaders("Set-Cookie");
if (headers.length == 1) {
extractCookieFromHeader(httpServletResponse, headers[0]);
} else {
// ignore the first header since there always seems two jsessionid headers
// and the 2nd is the valid one
for (int i = 1; i < headers.length; i++) {
extractCookieFromHeader(httpServletResponse, headers[i]);
}
}
}
httpServletResponse.sendRedirect(
stringLocation.replace(getProxyHostAndPort() + getProxyPath(), stringMyHostName));
return;
}
I was also able to remove the setProxyRequestCookies() method completely as it no longer seems necessary.
Next, I'd like to figure out how to make Spring Security more Ajax-friendly where it can read an authentication token in the request body or header (instead of from a cookie). Also, it'd be sweet if I could convince it to return error codes instead of the login page (for example, when a certain header is present).
Last week, I started working on a new project using GWT. On my last project, we used GWT HTTP Calls and my new project is using RPC. We'll likely migrate to a JSON backend eventually, but in the meantime, I wanted to be able to develop in hosted mode (localhost:8888) and call services on another host (localhost:8080), where the services are running in a JSF/Spring webapp.
At first, I thought it'd be easy thanks to the handy-dandy ProxyServlet I mentioned in Implementing OAuth with GWT. However, when I tried to hook it in and use it, I saw the following error in my server-side logs.
java.lang.NullPointerException
at javax.servlet.GenericServlet.getServletName(GenericServlet.java:322)
at javax.servlet.GenericServlet.log(GenericServlet.java:277)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.doGetSerializationPolicy(RemoteServiceServlet.java:219)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.getSerializationPolicy(RemoteServiceServlet.java:117)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader.java:429)
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:234)
Looking at RemoteServiceServlet.java:219, there's a logging call that fails for some reason (at least in my application).
/*
* Check that the module path must be in the same web app as the servlet
* itself. If you need to implement a scheme different than this, override
* this method.
*/
if (modulePath == null || !modulePath.startsWith(contextPath)) {
String message = "ERROR: The module path requested, "
+ modulePath
+ ", is not in the same web application as this servlet, "
+ contextPath
+ ". Your module may not be properly configured or your client and server code maybe out of date.";
log(message, null);
}
In the above code, you might notice that GWT is checking to make sure the client is hosted in the same application as the server. After I figured this out, it was pretty easy to modify my ProxyServlet to trick GWT RPC into thinking the client was in the same web application. In the ProxyServlet's handleContentPost method, I added the following code to replace "localhost:8888/" with "localhost:8080/services/" (in the content of the post to the server).
if (contentType.startsWith("text/x-gwt-rpc")) {
String clientHost = httpServletRequest.getLocalName();
if (clientHost.equals("127.0.0.1")) {
clientHost = "localhost";
}
int clientPort = httpServletRequest.getLocalPort();
String clientUrl = clientHost + ((clientPort != 80) ? ":" +
clientPort : "");
String serverUrl = stringProxyHost + ((intProxyPort != 80) ? ":" +
intProxyPort : "") + httpServletRequest.getServletPath();
postContent = postContent.replace(clientUrl , serverUrl);
}
After manipulating the posted content, I was successfully able to use GWT RPC cross-domain.
Woo hoo!
For your convenience, the full handleContentPost() method is listed below.
private void handleContentPost(PostMethod postMethodProxyRequest,
HttpServletRequest httpServletRequest)
throws IOException, ServletException {
StringBuilder content = new StringBuilder();
BufferedReader reader = httpServletRequest.getReader();
for (;;) {
String line = reader.readLine();
if (line == null) break;
content.append(line);
}
String contentType = httpServletRequest.getContentType();
String postContent = content.toString();
if (contentType.startsWith("text/x-gwt-rpc")) {
String clientHost = httpServletRequest.getLocalName();
if (clientHost.equals("127.0.0.1")) {
clientHost = "localhost";
}
int clientPort = httpServletRequest.getLocalPort();
String clientUrl = clientHost + ((clientPort != 80) ? ":" +
clientPort : "");
String serverUrl = stringProxyHost + ((intProxyPort != 80) ? ":" +
intProxyPort : "") + httpServletRequest.getServletPath();
postContent = postContent.replace(clientUrl , serverUrl);
}
String encoding = httpServletRequest.getCharacterEncoding();
debug("POST Content Type: " + contentType + " Encoding: " + encoding,
"Content: " + postContent);
StringRequestEntity entity;
try {
entity = new StringRequestEntity(postContent, contentType, encoding);
} catch (UnsupportedEncodingException e) {
throw new ServletException(e);
}
// Set the proxy request POST data
postMethodProxyRequest.setRequestEntity(entity);
}
Update: In the comments, Ganesh asked for more details, so I figured it'd be a good idea to post the full source code. First of all, click here to see the code for the ProxyServlet:
I generally subclass ProxyServlet to provide my own configuration:
public class MyProxyServlet extends ProxyServlet {
@Override
public void init(ServletConfig servletConfig) {
setFollowRedirects(true);
setRemovePrefix(false);
setProxyPort(8080);
}
}
Here's another example that reads configuration settings from web.xml and proxies to a different domain name:
public class AlternateHostProxyServlet extends ProxyServlet {
@Override
public void init(ServletConfig servletConfig) {
setProxyHost(servletConfig.getInitParameter("proxyHost"));
String secure = servletConfig.getInitParameter("secure");
if (secure != null) {
setSecure(Boolean.valueOf(secure));
}
setFollowRedirects(false);
setRemovePrefix(true);
setProxyPort(80);
}
}
After you've added these to your project, simply map the servlet (and its path) in your *.gwt.xml file (if you're using GWT) and your web.xml.
On Friday afternoon, the kids and I headed up to Winter Park for a night at Zephyr Lodge. The drive up was great (no traffic) and it started snowing as soon as we got off I-70. 45 minutes later and the kids were on the slopes for the last few runs of the day. There was a few inches of snow that turned out to be great - it slowed them down enough that they didn't have to turn or worry about "pizza".
On Saturday, we put Jack in Ski School and Abbie and I had a "Daddy + Daughter" day on the mountain. She didn't want to hit the magic carpet and instead opted for the lift right away. We skied a couple greens and w/in an hour she was ready to try a blue. She did quite well on the blue and even skied a few bumps on the side. Yes, she did fall a few times, but she got up by herself and always had a smile on her face. I was extremely proud. Below are a few pictures and a video from our weekend.
I'm glad I took the kids skiing yesterday. It's been dumping with cold temperatures ever since we left. It's currently -15°F in Denver (a new record) and it's snowed 2 feet at some resorts. Now I just need to figure out a way to make it up a couple of times this week.
This afternoon, I delivered my Building Rich Applications with Appcelerator talk for the 3rd time at Colorado Software Summit. When I first proposed this topic, I hadn't used Appcelerator and saw this as a good opportunity to learn more about it. I'm glad I did.
IMO, Appcelerator is a lot like Dojo in how it parses pages and turns HTML with special attributes into JavaScript widgets. I can't help but think a pre-compilation step would be nice to speed things up. I like Appcelerator's extensive Widget Library, and I especially like that they re-use many widgets rather than re-creating their own. Finally, I really dig the "SOA in a browser" approach where everything is a message and you can easily publish and subscribe to events - on the client and server. Below is my presentation, please let me know if you have any questions.