Important Notice - Forums is archived

To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Product icon

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.

Auth Frameworks

Rob Schoening
1 decade ago Dec 08, 2009 8:09pm

After a bit of tinkering, I have managed to get Vaadin working with Spring Security.

Ideally, one could simply protect the entire webapp from unauthenticated requests and be secure. Unfortunately, when using form-based security, this results in 302 redirects to some login page. This is fine for the main browser page, but confuses the GWT AJAX client, which don't know how to handle a 302 or 401 response. So if your authenticated session times out, the vaadin widgets in the browser will try to communicate with the server, which doesn't response correctly. The vaadin application appears to hang unless you hit the browser page reload.

The simple solution I used was to :

1) Leave the UIDL URIs completely unprotected so that unauthenticated sessions can communicate with the server
2) Take note of the fact that unauthenticated users can try to hack away at the vaadin ApplicationServlet all day long, but if it takes care not to instantiate a new application, nothing much will happen.
3) Extend the ApplicationServlet.getNewApplication() method to ensure that it will only instantiate a new Application instance if the request is authenticated
4) If getNewApplication() was called from an unauthenticated request, issue a redirect to get the auth provider (Spring Security in my case) to send the browser back to the login page.

This works OK, but obviously leaves an attack vector.

A more robust solution would be to enhance the client-side Vaadin code to look for 302 and 40x response codes and handle them properly. I did this with ZK a couple of years ago and contributed a patch. All it really has to do is interpret at 302 or 40x error code as an expired session.

It looks to me that this could be done fairly easily around line 363 in the following source:


I'll contribute a patch if I get a chance, but thought I would share first.

I think this would make Vaadin 10x easier to deploy in an enterprise context.

Great product, BTW. Very clean implementation.

Henri Muurimaa
1 decade ago Dec 09, 2009 8:20am
Petri Hakala
1 decade ago Dec 23, 2009 1:43pm

Vaadin 6.2.0 is now showing CommunicationError but if this is not acceptable you could make login.jsp to make JSON redirect. Check working example from incubator. I'm not sure if it works in every situation.


<%@page import="org.springframework.security.ui.savedrequest.SavedRequest"%>
<%@page import="org.springframework.security.ui.AbstractProcessingFilter"%>
SavedRequest savedRequest = (SavedRequest) session.getAttribute(AbstractProcessingFilter.SPRING_SECURITY_SAVED_REQUEST_KEY);
if(savedRequest.getRequestURI().indexOf("/UIDL/") != -1) {
	response.setContentType("application/json; charset=UTF-8");
	out.print("       {\"redirect\" : {\"url\" : \"" + request.getContextPath() + "/loginform.jsp" + "\"}} ");
} else {
	response.sendRedirect(request.getContextPath() + "/loginform.jsp");
Rob Schoening
1 decade ago Dec 26, 2009 4:48pm