Home > Aubrey Falconer > Content > Bug Reports > : Enhancing HTTP sessions using iFrames and JS
Enhancing HTTP sessions using iFrames and JS
8 Comments - 42232 Views
Advanced techniques to propigate sessions across multiple domains and deactivate them automatically!
Submitted By admin on 06/12/01
Aubrey Falconer, php, coding 
This originally posted in the "Aubrey Falconer" Group


The site you are viewing is a member of the ATI Network. All ATI Network sites share a common authentication system - even though the network spans multiple domain names. Logging in on one network site automatically logs you in to all the others, and leaving all network sites automatically logs you out of the entire network. How is this done? Read on:

How Sessions Work:

Pretend like you are a webserver. Your entire life is spent serving pages to clients over the internet. All you know about a client is what it tells you when it asks for a page. When a client sends you a page request, it looks something like this:

GET /index HTTP/1.1
Host: theati.net
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060308vFirefox/
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

This is all you need to know to serve them a page. But how can you tell different clients apart? How can you tell a guest from a registered user?
Each user must be given a unique ID, and that id must be sent along with each page request. This will allow you (the server), to reference each user to the data you have stored for that user, and customize the page according to their needs.

There are three main ways to get clients to send an ID along with their request:

  1. The most obvious option is to embed their id (in the form of GET data) in every url they visit by rewriting "on page" links.
    There are at least three problems with this approach:

    1. The first is with search engines. When a search engine visits a page, and has an id assigned to it, and has all the links rewritten to contain that id, every url it stores in its index will contain that id.Every person coming from that search engine will automatically "inherit" the search engines session. Worse, the next time the search engine comes back and you assign it a new id, all your sites links will appear to have changed. The search engine may get frustrated and leave!
    2. Another problem is with users copying urls. When an authenticated user copies a url out of their address bar and emails it to their friend, posts it to a forum, etc, their session will be "stolen" by anyone who visits that url.
    3. The final problem comes with histories. If a user logs into their account at a library or other public computer, completes their business, logs out, and leaves the computer, their session is "stealable" by anyone! All the next user of the computer has to do is press "back" a couple times, and they are logged in as the previous user!
  2. An extension of the first technique, it is possible to use javascript to detect link clicks, rewrite the link hrefs to a hidden form's action tag, and submit the form along with the session id in a hidden field. While this does get around the url copying issue, it adds a requirement for javascript and most browsers display an incredibly annoying "are you sure you want to go back?" dialog for any pages containing postdata.
  3. The best way is to give the client a cookie with their id inside, and have them give it back with every subsequent page request.
    The benefits of cookies are significant over url-based session preservation:
    1. Search engines, which generally don't accept cookies, are never presented with "changing" urls!
    2. Since cookies are not stored in the url, they can not be accidentally copied!
    3. Since logging out involves deleting the cookie from the client's computer, sessions can not be "hijacked" from the browsers history or cache!

    Cookies are less than perfect, however. Some people do not accept cookies, or may have their computer's date so far off that the cookies are deleted instantly. They are also not multi-domain. Some browsers reject cookies from all domains other than the currently visited one because of privacy issues. There is a way to work around this! Keep reading to find out how...

    Note that cookies and urls can both be stolen using techniques such as xss or a packet sniffer, so don't just assume your data is safe!

In summary: for most applications, cookies are better for session preservation than url rewriting. The rest of this article discusses how to use cookies to their full potential!

Multi Domain Cookies:

Since most browsers won't accept cookies from offsite domains, and since the browser must have a cookie for a domain to be authenticated in that domain, and since we want users to be able to log in to multiple domains at once, we will need to use a tool called iFrames to load cookie setting pages from each domain in the network on each network page.

How does it work, you ask? Simple. For our example, we will be setting up a network with three domains.When someone logs into d1.com, every subsequent page will have the following html appended to it:

<iframe xsrc="http://d2.com/loadcookie?id={SessionId}" width="0" height="0" frameborder="0"></iframe>
<iframe xsrc="http://d3.com/loadcookie?id={SessionId}" width="0" height="0" frameborder="0"></iframe>

This instructs our client's browser to request a cookie setting page from every other domain in the network. When that page is requested, the server replies with the following:

HTTP/1.x 200 OK
Date: Sat, 22 Apr 2006 02:16:05 GMT
Host: dX.com
Cache-Control: no-store, no-cache, must-revalidate
Set-Cookie: id={SessionId}; path=/; domain=.dX.com
Content-Type: text/html

Note that there is no expiry date set for the session cookie. This instructs the browser to delete the cookie as soon as the user's "session" ends, which is when they quit the browser. Below we will use javascript to delete the cookie when they leave the site, but this is there for users that don't have javascript.

Once finished, the browser will have separate cookies stored for every site in the network. No matter which domain the client requests a page from next, they will still be logged in!

You may be wondering why we don't instruct the browser to cache the iframes, and save several http requests per page. The reason is that since the cookies store the user's id, caching the iframes would allow session hijacking by loading the iframes from the browser's cache.

Auto Logouts:

Many sites "deactivate" sessions after a specific amount of time. They assume that if your session has not requested any new pages within a couple of hours, you probably aren't still sitting at your computer.
While this is better than not deactivating them at all, it has several flaws:

  1. Just because your last page request was 10 seconds ago doesn't mean you are at your computer! People can log in to their accounts at public places, complete their business, and then leave the site. Even though they may think their data is safe, in reality the next person to visit the site within the next couple of hours is logged into their account!
  2. People often have certain pages open for several hours at a time intentionally; especially when they are writing content. Imagine the frustration of spending hours writing an article, pressing submit, and being greeted with a login page after your article (in postdata) is lost in thin air!

While these problems can be mitigated by making it very clear to users that they are not safe till they have pressed "Log Out" and writing a complicated postdata preservation system, there is a better way!

Using javascript, it is possible to automatically log users out. Below is the code that does the trick:

function doCookie() {
var now = new Date(); //Create a date object
now.setTime(now.getTime() + 3000); //Set the object's time to three seconds in the future
document.cookie = "sessionname=sessionid; expires=" + now + "; path=/; domain=.thisdomain.com"; //Update their session cookie!
setInterval("doCookie()",1000); //Run function every second

As you can see, all it does is run in an endless loop, every second setting the cookie to expire three seconds in advance. When a user requests a new page on the site, The cookie is carried to the new page, and they are logged in. When they leave the site, the loop stops, and their browser automatically deletes the cookie within three seconds.

If the user doesn't have javascript, you can display a "be sure to remember to logout" message using the <noscript> tag.

Bringing it together - Conclusion:

Combining the iframe technique with auto logouts is easy, and provides an awesome session managing system!
All you have to do is add the javascript doCookie() code to the page the iframes request. That way when the multidomain iframes are loaded, the infinite cookie setting loop is instantiated for every domain in the network.
Whatever domain in the network the user requests by clicking a link, they are sure to have the session cookie for it. And when you leave the network, all the cookies delete themselves automatically by timing out!

Although I did invent both techniques described in this article on my own, I am now beginning to see some instances of iframes used as described here. As far as I know however, this is the first ever documented usage of javascript to automatically deactivate session cookies! And its nearly certainly the first use of them together! If you know of someone else using the javascript system, please tell me. And if you write an article about it, credit would be appreciated! :-)

You should now have a thorough understanding of the basic concepts behind http sessions, and a couple tricks up your sleeve for making them even better!
I hope you find many creative uses for the techniques presented here, and take them to new levels! Please post any ideas you have for improving these techniques in the comments.

» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
4 days - 12,819v
Posted 2010/12/24 - 2:37 GMT
Sweet. I commented on the oldest post of all. 1st comment.
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
8 hours - 1,253v
Posted 2011/09/19 - 23:48 GMT
If this is the very first post, then here is the very first, (drum roll please)...
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
7 hours - 11v
Posted 2011/12/08 - 3:28 GMT
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
5 days - 26,111v
Posted 2011/12/08 - 4:46 GMT
Don't bam old posts.
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
1 week - 32,767v
Posted 2012/07/30 - 6:47 GMT
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
1 week - 32,767v
Posted 2012/08/08 - 0:20 GMT
But what I don't understand is that when I log into Plexpedia, I'm not logged into Marsxplr.com, syn3h.com, TheATI.net, and other ATI sites, but I am logged into plexpedia groups, like Aubrey.plexpedia.com, colorshocks.plexpedia.com, lamp.plexpedia.com etc.

Then this whole post isnt true?
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
2 weeks - 19,756v
Posted 2012/08/09 - 4:36 GMT
You are correct, the techniques described in this article are no longer used to their full potential here. As the ATI Network expanded, it became impractical to cross-authenticate the number of domains which comprised it.
I am, however, currently using another rather cool technique I invented four years ago - I call it buffer tracking. It allows ATIServer to correlate certain elements of your active session to each browser window you have open. Each of your open browser windows has it's own history trail, alert messages, and any other relevant data an ATIServer application chooses to attach.
» Reply to Comment
Re: Enhancing HTTP sessions using iFrames and JS
4 days - 9,099v
Posted 2013/08/29 - 17:55 GMT

GenTime: 0.0207 seconds

Site Design and Graphics Copyright 2002 - 2020 by Aubrey
Use of this site constitutes agreement to our » Legal Stuff