Communication Errors + SingleSignOn/Acegi/SpringSecurity HTML forwards

Ok, interesting scenario here, - I’d be surprised if someone has not had this issue before.

So, My vaadin app runs within an App that is managed by Spring Security and CAS for single sign on.
It runs embedded in a div within a page that is served up by a Spring MVC controller. It could just as easily be in a static html page really, it wouldn’t matter.

Many enterprise Apps run behind a single sign or proxy type of security solution (eg, Siteminder) or something like spring security.

Spring Security in my case runs as a filter in front of the web application and protects all web requests. If a request is made when a session expires it forwards to the login page.
The login page is served by a servlet/controller and is a fairly standard HTML login page.
This is a good framework from a security perspective, as the security concern sits in front of the Application and filters all requests.
Popular single sign on solutions like Siteminder work in a similar manner.

What is happening here for me, is that Spring security does the forward to the login page for VAADIN engine requests when the session has expired.
The Login HTML is returned as a response becuse the session has expired.
Of course, the Vaadin clientr side cannot interpret the HTML and a “Communication” system error is displayed.

I understand this error can be customised in terms of Message and URL.
The problem is that it spits out all the response HTML in the error notification which looks horrible. It consumes the full page. The user simply will not know what to do when presented it every time their session has expired.

Is it possible to implement any custom listener for these Communication System errors? Or, - at least to suppress the response HTML from being displayed.
Displaying the response is arguably a security problem anyway, and its likely this will not get passed our security audit. (I know they can easily see the reponse anyway with something like Fiddler, - but the security folks will still not like this)

As an aside, the DWR ajax framework which I have used in the passed handles this nicely by detecting when an HTML response is returned instead of the expected JSON and invokinig a configured Listener.


OK, Have found the problem and have a solution for this, oulined below in case someone else runs into the same problem.

So, when embedding my Vaadin application, I have the following in the webpage that hosts the vaadin app.

<script type="text/javascript">
if(!vaadin || !vaadin.vaadinConfigurations) {
 if(!vaadin) { var vaadin = {}} 
vaadin.vaadinConfigurations = {};
if (!vaadin.themesLoaded) { vaadin.themesLoaded = {}; }
document.write('<iframe tabIndex="-1" id="__gwt_historyFrame" style="position:absolute;width:0;height:0;border:0;overflow:hidden;" src="javascript:false"></iframe>');
document.write("<script language='javascript' src='/client-reader-web/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/com.vaadin.terminal.gwt.DefaultWidgetSet.nocache.js?1309876466472'><\/script>");
 = {
versionInfo : {vaadinVersion:"6.5.0",applicationVersion:"NONVERSIONED"},
"comErrMsg": {"caption":"Communication problem",
"message" : "Take note of any unsaved data, and <u>click here<\/u> to continue.",
"url" : null},
[/b]"authErrMsg": {"caption":"Authentication problem","message" : "Take note of any unsaved data, and <u>click here<\/u> to continue.","url" : null}};

Removing the hardcoded “comErrMsg” configuration node results in my application being correctly redirected to the login page.

  1. How did you go about removing this?
  2. Won’t this impact all communication errors and not just authentication failures?