#67 bug
Per Melin

Ajax.Request#isSameOrigin should use location.hostname

Reported by Per Melin | May 1st, 2008 @ 09:30 PM | in After 1.7

It is sometimes necessary to manually set document.domain in your code, e.g when you have an iframe on a different subdomain than the main page.

See http://www.mozilla.org/projects/...

Once you change document.domain Ajax.Request#isSameOrigin will no longer tell the truth.

By looking at location.hostname instead you will always get a correct answer, because it cannot be changed (without redirecting the browser to a new page).

Comments and changes to this ticket

  • John-David Dalton

    John-David Dalton May 1st, 2008 @ 09:50 PM

    • Milestone set to
    • State changed from “new” to “bug”
  • Tobie Langel

    Tobie Langel May 2nd, 2008 @ 12:13 AM

    Looks like we should check for both document.domain and location.hostname. Are there any specs for this anywhere ?

  • Tobie Langel

    Tobie Langel May 2nd, 2008 @ 12:17 AM

    There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks.

    From the page you quote.

  • Per Melin

    Per Melin May 2nd, 2008 @ 12:25 AM

    Yes, a more ambitious and arguable more correct way would be to see if document.domain is a suffix of location.hostname and in that case compare to see if it is also a suffix of the host of the URL that is being requested.

    E.g if location.hostname == www.foo.com and document.domain == foo.com then bar.foo.com is the same origin.

  • Tobie Langel
  • Tobie Langel

    Tobie Langel May 2nd, 2008 @ 12:38 AM

    • Assigned user set to “Tobie Langel”
  • John-David Dalton

    John-David Dalton May 29th, 2008 @ 04:23 AM

    • Milestone changed from to 1.7
  • John-David Dalton

    John-David Dalton August 31st, 2008 @ 07:46 AM

    • State changed from “bug” to “invalid”
    • Tag set to ajax, needs_patch, needs_tests

    Ok guys,

    I chased this to a dead end. Once you set the document.domain to anything other than the current document.domain, ajax calls are disabled. That, and that ajax doesn't respect the exception mentioned above, is why people use iframe shims for cross subdoman communication.


    At this point it becomes pointless which one they look at.

    Though location.hostname is probably more accurate.

  • Mark Caudill

    Mark Caudill August 31st, 2008 @ 06:50 AM

    • Tag changed from ajax, needs_patch, needs_tests to ajax, ajax.request, needs_patch, needs_tests

    Based on some very preliminary testing, changing document.domain doesn't cease all Ajax requests, but it doesn't allow you to use it with other subdomains as the specs somewhat suggest.

    Requires iframe support in Ajax.Request to facilitate this functionality (1.7?).

  • John-David Dalton

    John-David Dalton August 31st, 2008 @ 07:46 AM

    This is quoted from the page I linked to above:

    The key is to do this in the right order. Once you set
    document.domain (to anything other then the actual host the page was
    served from) you lose the ability to make XmlHttpRequest calls. So
    you’ve got to take care of your XmlHttpRequest business before you set
    document.domain and to enable communicating with the parent frame.

    But you are right, I guess it was the late night, I thought I confirmed that behavior. I tested it again and could not reproduce it via firebug. The point remains that the exception in the Same Origin Policy doesn't apply to Ajax calls :D.

    I don't know if Prototype should handle the iframe shim. There are plenty of "howto's" on it and it requires placing files in certain sections of your website, this is a bit out of the domain of Prototype. A 3rd-party tutorial on this would be great though.

  • Per Melin

    Per Melin September 2nd, 2008 @ 12:13 AM


    The document you're linking to and quoting from is discussing an old bug in Firefox previous to 1.5 which would hinder ajax requests once you change document.domain.

    I'd say that the patch I attached when creating this ticket still stands.

    When my script executing on www.foo.com sets document.domain to "foo.com" to be able to communicate with an iframe at xxx.foo.com there is no reason for Prototype to stop my ajax requests to www.foo.com. But without the patch it does. It's a bug which is very easy to fix.

  • Mark Caudill

    Mark Caudill September 2nd, 2008 @ 12:23 AM

    • Title changed from “Ajax.Request#isSameOrigin looks at document.domain which is not reliable” to “Ajax.Request#isSameOrigin should use location.hostname”

    My original thought was that you were implying document.domain just couldn't be depended on and you must look at the wildcard of possible subdomains for that domain. That is what the specs you linked to implied, but we did figure out that it only affects iframes, as you've duly noted.

    I'd recommend this for since it's such a simple fix.

  • Per Melin

    Per Melin September 2nd, 2008 @ 12:52 AM

    Yeah, I wasn't very clear at all. But there are actually two problems. I put the emphasis on one (security), even though it was actually the other (breaking ajax) I really needed fixed.

    The first problem is, as we have established, that changing document.domain breaks Ajax.Request for no good reason.

    The second lies in that Prototype doesn't trust the browser to enforce the same origin policy, and so does its own check. But it checks the requested uri against document.domain, which should be almost worthless since it can easily be manipulated.

    location.hostname on the other hand can't be changed (without consequences) and would therefore be much better to compare with.

    The patch fixes both issues.

  • Tobie Langel

    Tobie Langel September 2nd, 2008 @ 03:08 AM

    Just to clarify, there is nothing preventing the request from happening, content is just not auto-evaled, unless you pass 'force' to either evalJS or eval JSON.

  • John-David Dalton

    John-David Dalton September 3rd, 2008 @ 05:30 AM

    • State changed from “invalid” to “bug”

    To add to Tobie's comments, failing isSameOrigin will cause the json argument of the ajax callbacks, which is response.headerJSON, as well as response.responseJSON to be sanitized (for good measure).

    I think that even though you can correct the behavior for auto-evaling scripts in the responseText with evalJSON: 'force', it's best to fix the bug and use location.hostname

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 01:54 AM

    • Tag changed from ajax, ajax.request, needs_patch, needs_tests to needs_patch, needs_tests, section:ajax

    [not-tagged:"ajax" tagged:"section:ajax" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:26 AM

    • Tag changed from needs_patch, needs_tests, section:ajax to missing:tests, needs_patch, section:ajax

    [not-tagged:"needs_tests" tagged:"missing:tests" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:28 AM

    • Tag changed from missing:tests, needs_patch, section:ajax to missing:patch, missing:tests, section:ajax

    [not-tagged:"needs_patch" tagged:"missing:patch" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:36 AM

    • Tag changed from missing:patch, missing:tests, section:ajax to missing:patch, needs:tests, section:ajax

    [not-tagged:"missing:tests" tagged:"needs:tests" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:37 AM

    • Tag changed from missing:patch, needs:tests, section:ajax to needs:patch, needs:tests, section:ajax

    [not-tagged:"missing:patch" tagged:"needs:patch" bulk edit command]

  • T.J. Crowder

    T.J. Crowder November 16th, 2009 @ 04:50 PM

    • Assigned user cleared.

    [responsible:none bulk edit command]

  • Andrew Dupont

    Andrew Dupont October 19th, 2010 @ 01:16 AM

    • Importance changed from “” to “Low”

    Pushing this back to the next milestone.

  • Andrew Dupont

    Andrew Dupont October 19th, 2010 @ 01:17 AM

    • Milestone changed from 1.7 to After 1.7

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

The Prototype JavaScript library.

Shared Ticket Bins