Many developers understand cookies from a simple perspective that it is responsible for preserving state conversations in a web application and has an expiration interval. They also perhaps are aware that cookies can be created at the server side with a session identifier and pushed to client browser. Beyond this, many drew a blank when they are faced with issues such as timeouts, cross domain communication, and multi browser initiation.
Under the hood there are two types, session and persistent cookies. The former has no lifetime beyond opening and closing of browser window, whereas the later can be retained for unlimited period of time and when created is written into browser cookie store on client machines. Besides, expiration intervals cookies have affinitiy to domains from which they originate. For example, "myspace.com", "client1.myspace.com", "secure.myspace.com", etc., can share the same cookie because they are either domains or subdomains of same type. This is easily achieved by explicitly setting "domain" property of cookie object to the other subdomain before streaming the output response (Most languages/scripts have cookie API with domain property). User apps can then navigate to and reference to links, images, scripts or resources within each other. However, if your infrastructure has systems in "myspace.com" and "myotherspace.com", then you will not be able to cross reference resources from each other. That would amount to cross site scripting attack and you may have to workaround at DNS level spoofing the IP addresses of these domains so that browsers can work without throwing "Internal Server Error".
One other issue with cookies related to timeout emerge from modern browsers having tab feature. Users opening multiple browsers or tabs end up sharing the same cookie, meaning users are logged once but have multiple handles to the same server side session. This could pose serious problems to your applications depending on what they are trying to do. For example, user on one browser frame window may update a record and in parallel try to delete that record from other window or tab. Now that this user is attached to the same server session, there could be a data collision.
If your application can allow multiple view access to same server session, for most part a convenience for users to compare and work across screens, then you may likely be limiting users to one session cookie and do not mind if they use multiple tab windows. However, if you want one and only one view representation of your system you just simply cannot rely on cookies. Cookies are controlled by window frame process and is shared across tab processes (in most browsers). On IE8, you have a feature to start a new session on your tab which decouples that tab from frame process thus establishing a new session with server. For browsers that do not have this feature, developers need to create home grown solutions like generating, encoding and attaching a windows handle ID to every URL request just like what one would do with sessionID if there were no cookies. On the server end you would associate this handle to one particular session token, user requests from other tabs or window processes will have different handle that will now be rejected. There are some server side frameworks (eg. Spring 3.2+) that can create cookies specific to tab handle instead of a javascript approach.
No comments:
Post a Comment