Skip to content
June 12, 2010 / edeustace

Patching Josso 1.8.0 logout mechanism to maintain the josso_back_to parameter

On my current project we use Josso as the sso solution. This is all well and good, but Josso is not designed to work with Ajax or flex apps out of the box. It is more suited to a standard multipage style website, where you can restrict access to some resources in your website.

I’m going to put the cart before the horse and explain a few patches that I’ve had to apply to Josso, without giving a detailed explanation of how my Flex application works with Josso. I shall add that post shortly.

The problem:
When calling logout from my flex client, I am invoking Josso Gateway logout function eg: This is being called by a HttpService object within the Flex application.

To this call I add a parameter to inform Josso where I’d like to be redirected to. For this redirect I ask Josso to return me to*, which is a simple servlet that checks that the UserPrincipal is null and so proves that a successful logout has occurred. This servlet then returns a “true” or “false” back to the flex client to indicate success (or not).

Here is a simple flow diagram:

However, the Josso administrator recently added a caching mechanism to the Josso gateway. This has caused my logout mechanism to fail.

If I use “/josso_logout” on my Agent server then the logout is successful even with the new cache that was added.

This call basically does a bit of tidy up on the agent, then redirects to The problem with this call is that the josso_back_to parameter that I specify gets stripped by Josso and instead it adds the root context of the application.

So if I call:
/josso_logout redirects to:

Which is the root of my app. This is not desirable for my flex app because the contents of is going to be a jsp or html that will be consumed by my Flex HttpService, when all my service is expecting is a “true” or “false”.

Its a bit of a puzzler why this caching is now breaking my logout mechanism. Gianluca the creator of Josso, even recommends calling directly on the gateway, so that you can specify your own josso_back_to.

So in summary, the problem is how to patch Josso to that it maintains my josso_back_to parameter:
So if I call:
/josso_logout redirects to:

Here is sequence diagram showing the current solution:

The patch:
Looking at SSOAgentValve.invoke() we have:

// ------------------------------------------------------------------
// Check if the partner application required a logout
// ------------------------------------------------------------------
if (hreq.getRequestURI().endsWith(_agent.getJOSSOLogoutUri())) 
     String logoutUrl = _agent.buildLogoutUrl(hreq);
     // Clear previous COOKIE ...
     Cookie ssoCookie = _agent.newJossoCookie(request.getContextPath(), "-");

In _agent.buildLogoutUrl the josso_back_to parameter isn’t being maintained. To patch this I added to HttpSSOAgent.buildBackToUrl():

else if (hreq.getParameter("josso_back_to") != null )
if (debug >= 1)
          log("[patch] original request contains a josso_back_to url: " + hreq.getParameter("josso_back_to"));
backto = hreq.getParameter("josso_back_to");

I’ve just done some initial tests and everything is back to normal again. Its a simple patch, but very handy. I’ll post it on the Josso forums to see if its any use to anyone.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: