Weird Thoughts From Eric's Head

Categories : All | AJAX | BUSINESS | PERSONAL | PROGRAMMING | BOOK REVIEW
Permalink
[AJAX] [PROGRAMMING]
Ajax: Session Warning to Developers
Your application probably has one of these problems!

Ajax: Session Warning to Developers

One thing that you have to think about when developing an Ajax application is the user's session. Now there are two ways it can bite you in the butt. With first hand experience, I have seen these in other people’s applications and mine. Why it is a warning? They can cause some major problems if we do not account for them. Problem 1 can lead to security issues with a long lunch break and Problem 2 can just leave a user hanging wondering why the clicking the button 20 times did nothing!

Problem 1: Unwanted Extended Sessions

The first one I want to talk about is polling the server for information on an interval. This is common on sites to get stock information, performs auto saves, finds those sports scores, and poll for other data that is updated regularly. Let's say you have a forum where you have Ajax code to update the number of members that are currently on the site. Now you have a session timeout of 20 minutes set on your server, but you make a request every minute to get the member count. The request is sent to a server side page that returns the result in a formatted text string. This means every minute that user's session is updated to get this information.

So what do we do?

Well you have two choices. The first choice is to move the information to a file type that does not affect session. Some external process on the server can update the file with the information. This is great if we are talking about data that does not rely on user information. But if our data relies on user information and the session needs to be involved?

We need to basically create our own session monitoring code. It is a lot of work, but if session is important for security, then you are required to go through this pain in the butt process. We need to build functionality on the server that monitors the last know server side activity that the user performed. So you basically add a timestamp to something that you want to monitor. Could be a database field, cached values, session, or whatever fits your application coding requirements.

Now that you have this timestamp you can do a few things. First thing is you can act like a classic timeout, kill the session and forward the user to the login page when the user posts back the page. Next thing you can do is have your Ajax polling check the time difference between the last user activity and if the time is greater than your set value, kill the session and have the page redirect the user to the login page. Now both those methods can be rather mean, so you can basically implement something like my Ajax session notification. (Not the same thing, but gives you an idea!) You could have them click a button to extend (update the session timestamp) or have it time out and give the user a message. This way it is more user friendly.

There are tons of ways to implement solutions to this problem, it is up to you to find ones that meet your needs, but if you are not polling the server, you may run into a bigger problem!

Problem 2: The dreaded Session Timeout

Now as I have told you in the past, I log all of my clientside errors so I can see that there is a problem with my code. The best testing can not find every browser combination of security levels and OS types out there. (I will be talking about logging clientside errors at The Ajax Experience.) One error that I found creeping up was rather weird. In my application I check to see if the response from the server was in the valid format that it expects and it checks for error messages returned from the server which tell the browser what to do. But in this case normally late at night or after lunch I would see five errors in a row with

Error
Reason: Bad Response From Server
Response: <html><head><title>Login...

Tackle the problem

Now something that never crept into my mind was session running out. I thought it was rather cool seeing that the session expired on me. So now when I get the response back from the server, I now check to see if the user was sent to the login page. To do this, I use an indexOf against the responseText to check for a phrase on the page. Now if I get a location that is not -1, I know the user's session is gone and cause the current page to submit. (Do not redirect them their since your page will probably not send them back to the right page!) In return the submission of the page will see the expired session and send them to the login page, just like the XMLHttpRequest object went through.

Now I saw this with an auto-complete field and other custom controls on the page. Now you may be thinking to yourself, my session is very long, it does not matter. Well I must say that my session limits are very long, longer than most, due to the amount of forms and nature of the material. When I first heard of the length and saw this problem I laughed and said to myself: "people need to learn to save and logout for security reasons!"

If for some reason you have been developing in the ideal world your whole life, you need to realize that some user's think that your webpage is like a word document. That document just sits there open on their desktop for days with unsaved change and they will have the data when they come back when they finally close it and it prompts them to save. They do not realize that the web does not act this way, but try to do it anyway!

Wrap it up:

Now the thing that scares me is if I did not log my clientside errors and know my code that well, I would have never seen these problems happen. The first problem is common sense, but a lot of people forget about this, or thing that the XMLHttpRequest defies all laws of nature. Sad to say they all still apply! Now how do all of the toolkits out there conform to these two problems? Has anyone tested them in these situations? I would advise anyone out there running a toolkit or self written code to run these tests!



Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages


I am running into the same problem #2. I first thought I would simply get the location header for a 3xx HTTP status (returned from the server) and have my JS code redirect to to the login page, using that url, but soon realized that Firefox (not sure what behaviour to expect from IE) does the redirection under the covers for you (Mark Nottingham creating a set of test cases to understand the different XMLHttpRequest behaviours). I find using an indexOf to figure that a session timeout occured rather fragile considering that the login page can change on the server, but maybe there is no better alternative?
We have gone into problem #1. We have set the interval of AJAX refresh time larger than the actual server session timeout interval. However, if there are so many users using the server, the server hangs on waiting / clearing sessions. Maybe we'll need to implement a session timeout monitor.
Maybe we'll need to implement a session timeout monitor.
What you need is MessAdmin, a free J2EE monitoring utility that tracks what's going on in your server. You can track your user sessions, send them messages, and much much more. Check it out! :)
I also ran into this problem and I did the following: If an AJAX request is made that requires a session/authentication, and the session has expired, I send a HTTP authentication request. A nice auth box popups in the user's browser, saying 'Your session has expired, please login again'. The user logs in and the request is handled as normal. This way the user stays on the same page and doesn't have to go to a seperate login page where all his/her work goes lost. For an example on how to do this with PHP, see the PHP manual. If you run PHP under (fast)cgi, you also have make some modifications so that the HTTP auth is passed to PHP (it doesn't do this by default, afaik).
When I was developing our CMS I ran into problem #2. I fixed it by having the system show a popup window with a "you have been logged out, please log in again" message and the login form. The whole process is independent of the original editing window so they're able to login without interrupting their editing session and possibly losing data.


Add a comment

Title
Body
HTML : b, i, blockquote, br, p, pre, a href="", ul, ol, li
Math Quiz 4 + 3 = (Helps stop blog spam)
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).

TrackBack to http://radio.javaranch.com/pascarello/addTrackBack.action?entry=1139887007801