Session tracking

[punktniklas]

Hi!

I'm currently developing a customer care web front end for a billing system using Java Servlets/JSP. I have run into a problem where I need some general advice on best practices, design patterns etc.

The web application we are doing is a replacement of an old web application using perl CGI scripts. This old solution doesn't have any session tracking on the server side and all session data (which CSR is logged in, what customer is being maintained and other things) is passed from web page to web page using forms with lots of hidden variables.

In the new solution we are using the built in session tracking using cookies, storing session data on the server side. This solution has a lot of benefits when it comes to designing an developing the system. One drawback that we didn't think of in the beginning has been raised though..

The users of the old system are used to being able to use the back button of the web browser in any way they please. They are also used to being able to open new browser windows to e.g. maintain two accounts at the same time. In the old solution you could do like this because all state was stored on the client side and every web page contained sort of a snapshot of the state at that point in time. Doing the same thing with the new system confuses the hell out if it because state is stored on the server side and all browser windows are accessing the same session.

This problem must have arisen many times before in various projects. What is the usual way to deal with it? Is there a usual way? Any comments, ideas, pointers are welcome!

/Niklas

[Waylander]

Im not really seeing where the problem is here, session tracking in web applications can be done quite well and with a resonable level of user friendlyness. I wasnt aware of the back button having any real siginifcant impact. As long as they dont close the browser or move too far to back out of the pages everything should be fine if you code it right.

Some of what you want can probably be done, some more of it also could be but im sure that some developers wouldnt recommend doing so. Having a central data location and maintaining data itegrity are simply too important to abandon for ease of use.

Anything regarding user authentication should be able to be handled completely by the server... doing anything on the client with hidden variables and to a lesser extent cookies (or any other client side techology) is generally considered to be a bad idea, as it is too easy now a days for these technologies to be altered and emulated. Posing somewhat of a large security risk.

I would recommend trying to implement each part of the functionality you want with only server side technology, if you get to the point of turning to client side technologys for something specific, search the net or ask again here if there is a way to accomplish it on the server and if there isnt then I would recommend discontinuing it and spending your development time on more worthy system components.

A fair bit of what you want to do is definately feasible up to a certain point.

Good Luck with everything :) let us know how you fair.

Waylander.