At what point should I change the way Struts acquires the session token?

Question

It seems I have to find a different way to transmit the session token from a Flex client to a Struts backend without using cookies.

If I were to put the session token in the payload of a request, at what point would I have to customize Struts' behaviour so that I can reuse as much of the existing session handling as possible? In particular, I don't want to reimplement whatever security measures (such as tying a token to an IP) and configuration parameters (such as session expiration interval).

There's a CreateSession interceptor, rather early in the default stack, should I swap that with a subclassed version?

Answer 1

I'm not very experienced with Flex but as this seemed interesting and I do not like to see questions go unanswered I thought I would have a stab at it. As I understand it the Flex session (HttpFlexSession) and the HttpSession are completely separate entities. That said you should be able to share data between them.

There is a very relevant free chapter (Chapter 20: Flex Integration with J2EE) available from the book "Developing Rich Clients with Macromedia Flex" by Steven Webster and Alistair McLeod.

I will now quote heavily from that free chapter! Of particular note:

Maintaining State

The biggest leap in understanding to be made is that there's no longer a need for HTTP session state. Although your requests between rich client and server are ultimately being made over HTTP, HTTP has been reduced to a transport technology instead of a technology that we need to integrate with. J2EE developers are comfortable with the concept of placing attributes and parameters in the HTTP request and response objects, and maintaining state by storing objects in the HTTP session. ...

... Flex can in fact offer access to the HTTP session and allow the Flex client to treat the HTTP session as "just another object on the server." However, in our experience, using the HTTP session should be a "bad smell" that identifes a refactoring opportunity to shift some of your application state onto the client.

Later on in this chapter it shows you how to configure the session object for Flex client access.

Gaining Access to J2EE Sessions

Flex preconfigures a session servlet in the default web.xml file, which makes available a server-side Java object that can be used to access and modify the J2EE session for an application. By placing one of the following Remote object definitions in our Service Locator at services.mxml, we make available to our application a service that can get and set objects in the J2EE session, as well as remove objects from the session:

<mx:Remote object source="servlet" id="sessionObject" /> 
<mx:Remote object source="@ContextRoot()" id="sessionObject"/>

As with any other <mx:RemoteObject> tag, the session service can use result and fault event handlers to handle requests to fetch items from the session. The web.xml descriptor defines the name of the session servlet as servlet; therefore, we use one of the following examples to work with the J2EE session:

sessionObject.session( "set","customerID", 700 );
sessionObject.session( "get", "customerID" ); 
sessionObject.session("remove", "customerID" );

These three examples demonstrate how the session service is used to get, set, or remove items in the J2EE session from a Flex client.

So it would seem that although you can share session data between Flex and backend Java, however, the suggestion seems to be that this is an anti-pattern.

With respect to security measures, if you were using Servlet Filters to implement IP restriction then your security could be applied to all the resources in your web application (irrespective of whether it was of Struts or Flex origin).