[webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

[Mihai Parparita]

On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> 1) It means the access control goes in fewer places - we don't have to have
> access control on every document property, only window properties.

I'm not quite sure I understand this. At least for the location
object, I see an explicit check in JSLocationCustom.cpp:
http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSLocationCustom.cpp#L71.
Throwing the exception would happen there too (it won't require custom
getters for each property).

> So in general I'm not in a rush to change this. However, if the original bug
> involved a compatibility problem on a real site (it doesn't really say),
> then maybe that would be a stronger reason to change.

I've asked Joseph (the original reporter of http://crbug.com/17325)
where he ran into this. However, in the meantime, a quick code search
shows this pattern elsewhere too. For example, Dojo has this snippet
(in http://svn.dojotoolkit.org/src/dojo/trunk/hash.js):

try{
  //see if we can access the iframe's location without a permission denied error
  var iframeSearch = _getSegment(iframeLoc.href, "?");
  //good, the iframe is same origin (no thrown exception)

And FCKEditor (a WYSIWYG editor) has this at
http://dev.ckeditor.com/browser/FCKeditor/trunk/fckeditor.js#L167:

try
{
        if ( (/fcksource=true/i).test( window.top.location.search ) )
                sFile = 'fckeditor.original.html' ;
}
catch (e) { /* Ignore it. Much probably we are inside a FRAME where
the "top" is in another domain (security error). */ }

Mihai