Sessions with Flex and Flash

I’m looking for corroboration, confirmation, and/or corrections, so if you got ’em, throw ’em in the comments please and I’ll update this post.

The more popular Flex and Flash gets, the more exposure I get to large server-side development teams. As most have developed a lot of web based applications, the question of session handling comes up time and time again. I’ve attempted to compare and contrast the current known methods for utilizing sessions in a web browser, and their parrellels with Flex & Flash development. My goal is to better understand why you do or do not need session handling in your web application.

In this post’s context, a session is defined as a way to uniquely indentify the client to the server. Since normal http interactions are stateless, there is no way for a request from the client web browser to the server to be uniquely identified. Where such situations are needed to know which client is which, and keep data associated with that client while they are interacting with the web application, a sessions is used. The real-world example is keep a list of items a user has added to their cart in an ecommerce site. Even if they go from page to page throughout the site, or back, the session keeps track of their cart items.

The three main ways to do this are:

  1. appending variables to the URL string
  2. hidden form field
  3. cookies

The first way involves appending variables that are relevant to the web application state to the end of the URL and making sure each page continues to attach this information along as well. Hyperlinks may add &id=234890somerandomnum&cartitem1=someproductid to the end of the URL when travelling from page to page. The server-side code garner’s context, if needed, since these variables are passed to the server before processing the next page. The pro’s to this is you can easily see what variables are working during development, and this allows you to tweak your pages to test things while using the app. The cons are unweildy URL’s that are extremely long, if you miss passing one variable the whole thing gets fubarred, and harder to secure (assuming your methods handling the server-side variables don’t check for arbitrary data which they should).

The second way involves sticking a session ID or even additional vars like the above into a hidden form field(s).

The third way involves utilizing cookies that store session information. Pro is this is very application transparent for the front end, but the con is if cookies are disabled, it won’t work.

My take as to why server-side developers like sessions is that role information is encapsulated into the request. In the case of AMFPHP for example, each server-side method in a PHP class has a role or set of roles that are allowed to call it. Upon logging in using normal browser security, you’re role is set. This provides transparent interaction between client and server. You can even handle a custom fault of not having the role privaledge to access certain functionality, or even “re-login” if need be without refreshing the page. I guess I don’t understand where this persists, though. J2EE has a similiar setup with a nice, built-in security that works.

The state arguments, however, make no sense. It is understandable since it requires a lot of effort to work with the developers to get them out of the “page” mindset. There is no page; it’s an application like Outlook; it has state, and doesn’t lose it. There is no page refresh.

I once worked on a Flash app where in using OpenAMF, the Java guy wanted me to pass him the session ID as the first parameter to every method call. I’d login, get the sessionID as a return value, and set it to a global (static) variable in the Flash app. Every Delegate call pre-pended this value as the first parameter to method calls. It wasn’t so bad, but I never really understood what the session gave us.

The hidden form variable works similiar to the above; you just store whatever variables you want to keep around in a global/static class.

While Flex & Flash have their own cookies, they are used for ensuring data persistence across application usage, not sessions. So, if I reboot my computer after using an application, the data will be there tomorrow type of thing. They are for data storage. Just like browser cookies I guess, only harder to delete (harder meaning not built into web browsers like cookies are).

The current Flex & ColdFusion app I work on, we don’t use ’em. The Flex app keeps state, and just calls ColdFusion CRUD methods. I’m sure we could add roles if need be, but I guess I just don’t get it beyond the built in security some server-side technology has to authenticate requests.

I’ve never really found a definitive article explaining the session’s role in Flash & Flex development. I’ve seen it discussed more on Flexcoders, but this is mainly because of the influx of server-side talent on that list who is used to dealing with such state. The typical response is “you don’t need them, Flex is a stateful client”, and yet the “logging in” is still discussed. If anyone has anymore sources to add to the above (or correct), please link.

17 Replies to “Sessions with Flex and Flash”

  1. I don’t have an article to point you to, but from my experience I use sessions to track security mainly. Like the example you mentioned, log in and have the user authenticate before they can call any other remote methods. In AMF you can attach informatoin to the header. This works sort of like the example you mentioned, where the first paramater is the sessionId, except you place it in the header information of your remoting service instance and never again. This will give you the benefit of sending the sessionId everytime you make a remoting call to the server, and the server can authenticate it, but you don’t have to have it pollute your api where every first paramater is the sessionId.

    ColdFusion supports this built-in, the .Net remoting connector from Macromedia doesn’t. I had to build a custom gateway that inspected all amf data coming into the back-end and checked for the sessionId, it is actually pretty simple to do.

    I like this setup a lot and haven’t felt the need to do it another way since I’ve adopted it

  2. The problem with sessions comes mainly from people coming from server-side development. Is difficult for them to change from traditional web page centric development to RIA development, where we have an stateful client that could handle all task before related to the server. Sessions was invented to workaround a problem that doesn’t exits anymore in Flash/Flex.

  3. I do not see the session usefullness myself completely for a running application. I however (as a flash / flex user) do use it myself for 1 thing.

    In the webpage that serves my swf, i set a UUID in memory of the server, in the session scope. Within the application i call a webpage that serves xml. This webpage however only serves the xml if the id i send to it is the same as the one in the session memory. This prevents a user from using my application anywhere else then on our server.

    This is the only use of the session we have, the rest of the application does not use it. All other calls just pass the info needed to fullfill the request.

    There is no need to send a session ID to the server if you have serverside cookie based session management enabled. Every request to the server will automaticly use the session stored in the cookie, even remoting calls.

    Greetz EE

  4. We use sessions in combinations with our Flex 1.5 app to track security only.

    We have visitor and owner role for the content, thus we must track the current logged in user at the server by the help of session handling.

  5. Hi Jesse,

    Sessions is a convenient way to store user-related data on the server as well as it helps to identify a particular user on the server (what is sometimes referred to as security). Just wondering how would you track the user after login without sessions?
    There are two options:
    1) you pass login/passwpord information with every request so the server knows who u’re – i beleive we’re all understand that’s inapproriate.
    2)you pass some kind of uniquely generated parameter (basically session ID ;) with every server request so the server knows who u’re

    Regards,
    Alex

  6. I too have been trying to integrate Flex sessions with Rails and authenticating users. The method I finally decided on involved firstly ‘logging in’ and posting the username and password to the Rails backend. Rails would then generate a random ‘remembrall’ in response (if the user successfully logged in) and also set a time and date for the remembrall’s expiry. Then, any further requests from the flex application to the rails backend would include the ‘remembrall’ in order to authenticate the request (I have heard that Flex allows you to include this in the header). Here’s the link for the rails code in case you interested:
    http://alexmaccaw.no-ip.info/flex_rails_sessions/sessions.txt

  7. This is great. I’ve been trying to figure this out as well. I started in ASP back in the day before I moved to Flash, Flex and AMFPHP or ASP.NET. So it sounds like AMFPHP handles the creating and maintaining the sessions for me.

    What I’m still confused about is how do you handle timeouts? How do you make a Flex/Flash app go back to the login screen screen after x num of minutes?

  8. The session times out on the server, and you’ll get an error thrown server-side that you can catch client slide. I believe you can configure how longs sessions last in ASP, .NET, Java, PHP, etc. Don’t know how, but I remember talking to a developer that said you could.

    You can just look for a session timeout error in a base onFault handler for AMFPHP’s remoting, and then pop-up a modal login dialogue. This is nice because the user doesn’t have to lose what they were doing; stateful clients == pimp!

    If you get it working Judah, blog an example so we can see.

  9. What about security concern, how doe one make sure that the server is talking to the same client that was authenticated and what about the issue of entitlement?

  10. Hello everybody! PROBLEM IS: IF I REFRESH THE login PAGE THE LOGIN POPS UP AGAIN! I MEAN I LOGGED IN IN THE APPLICATION, BUT THEN IF I CLICK ON REFReSH PAGE THE PAGE SHOWS ME AGAIN THE LOGIN PAGE!
    PLEASE LET ME KNOW HOW IT IS POSSIBILE TO HANDLE THIS!
    ANOTHER EXAMPLE:IF YOU HAVE A LIST OF THINGS YOU ARE BUYING ON THE WEBSITE AND YOU REFRESH THE PAGE(F5), IT LOSES ALL THE PRODUCTS! NORMALLY IT SHOULD not BEHAVE LIKE THIS, HOW IS IT POSSIBBLE TO HANDLE THIS?
    THANK YOU A LOT,
    GABRI

  11. Gentlemen,

    I use mx:remoteobjects to comunicate with java-server and cookies are disabled on it.
    How can I attach jssesionid header to my remoteobject’s calls?
    Any help will be appreciated.

Comments are closed.