Iframes, third-party cookies and the document.domain property

Published April 18th, 2008

I’ve spent the last few days re-writing our login process to handle a switch to using a third-party server for user tracking. Specifically, where before the login and tracking was handled by the same domain, now the login is processed at one domain but the tracking cookie is served on a subdomain (for technical reasons that aren’t really important here).

Getting this to work has had me (metaphorically at least) banging my head on the desk. For a start, the login process uses an iframe to call across to the subdomain so that it can set a cookie. This works fine (in some browsers anyway) but then you run into cross-domain security issues when trying to communicate between the iframe and its parent document (‘permission denied’ in IE/FF, ‘Security error: attempted to read protected variable’ in Opera, ‘Unsafe JavaScript attempt to access frame’ in Safari). On top of that, Internet Explorer just flat out refuses to register the cookie because it classes it as ‘third-party’*.

I was getting close to giving up and reconsidering the whole set-up, when I stumbled across the magic bullet: document.domain. This property — which instantly fixed all the browsers I was testing — effectively allows you to ‘broaden’ the domain of a third-party document, so that the browser treats all documents as originating from the same domain. So for example whereas my parent document is at www.mydomain.com and the iframe is on auth.mydomain.com, the following JavaScript code (in both the parent and iframe documents):

document.domain = 'mydomain.com';

…tells them both to use the same domain.

Just thinking of the hours I’ve wasted trying to work around these problems, when the fix was so simple, makes me want to cry. Hey ho.

FYI it only works when the domain is the same — you couldn’t use this to allow communication between frames from, say www.mydomain.com and www.yourdomain.com.

[* The third-party cookie problem with IE also required setting a compact domain policy.]

Get a Trackback link

4 Comments

  1. steve on September 22, 2008

    Didn’t you also have to add the two sites as trusted sites to be able to interact between the javascripts in the iframe document and the parent document?

    Thanks.
    Steve

  2. Stickman on September 23, 2008

    Steve: no, that’s exactly what I wanted to avoid! The document.domain setting gets around this by telling the browser to ‘ignore’ the subdomain so that it recognises both domains as being the same. Also, please notice the footnote regarding the compact domain policy — this is an additional requirement for Internet Explorer.

  3. DRR on October 15, 2009

    but what if you don’t have access to the outside-party javascript?

  4. Michael Pedzotti on May 28, 2010

    Stickman, I understand from what you are saying that an iframe with src=www.domain1.com will therefore not pass cookies to the browser if it is hosted on, for example, http://www.domain2.com.

    I have been searching everywhere for a workaround for this. Your post answers some questions but I wonder if you have since heard about establishing cross domain trust.

Leave a comment

Comment Policy: First time comments are moderated. Please be patient.

OpenID

Anonymous