Prototype

Comments and changes to this ticket

• 

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

  • → Milestone changed from “” to “1.6.0.3”
  • → State changed from “new” to “bug”
• 

  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 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 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 May 2nd, 2008 @ 12:38 AM

  For reference:

  http://www.w3.org/TR/DOM-Level-2...

  http://developer.mozilla.org/en/...

• 

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

  • → Assigned user changed from “” to “Tobie Langel”
• 

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

  • → Milestone changed from “1.6.0.3” to “1.6.1”
• 

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

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

  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.

  http://www.fettig.net/weblog/2005/11/28/how-to-make-xmlhttprequest-connections-to-another-server-in-your-domain/

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

  Though location.hostname is probably more accurate.

• 

  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 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 September 2nd, 2008 @ 12:13 AM

  John-David,

  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 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 1.6.0.3 since it's such a simple fix.

• 

  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 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 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