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

[Adam Barth]

I've started a thread on whatwg in case folks with like to discuss
this topic further:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035188.html

Thanks,
Adam


On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <abarth at webkit.org> wrote:
> I wonder if we could expose the parent document's origin, so you could
> write the check as follows:
>
> if (parent.location.origin != location.origin)
>    return;
>
> It's slightly subtle because we wouldn't want to expose the origin of
> child frames (then you could probe the redirect structure of private
> networks), but exposing ancestor origins seems tenable.
>
> Adam
>
>
> On Thu, Mar 22, 2012 at 9:16 PM, David Levin <levin at chromium.org> wrote:
>> Suppose I am using a framework does window.frameElement for various
>> reasons. When that framework is used in an iframe, it causes errors to
>> appear in the console.
>>
>> For example, suppose the framework does this:
>>
>> var a;
>> try {
>>     a = window.frameElement; // WebKit outputs a console error here.
>>     if (!a)
>>         return;
>> } catch (e) {
>>     return;
>> }
>> ...
>>
>>
>> Now if I had this new method, I would change the framework to do this:
>>
>> var a;
>> try {
>>     // WebKit doesn't throw an exception for x-origin parent access, but it
>> will puts errors in the console.
>>     // Do an explicit access check to avoid having the error appear in the
>> console.
>>     var canAccessParent = window.parent.webkitCanAccess;
>>     if (canAccessParent != undefined && !canAccessParent)
>>         return;
>>     a = window.frameElement;
>>     if (!a)
>>         return;
>> } catch (e) {
>>     return;
>> }
>> ...
>>
>>
>> Does that help? (The use case is about avoiding spurious console error
>> messages, so console error messages are real errors.)
>>
>> dave
>>
>>
>> On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <weinig at apple.com> wrote:
>>>
>>> Hey Dave,
>>>
>>> Can you describe the use case for this new property?  When would an author
>>> use it?
>>>
>>> -Sam
>>>
>>> On Mar 22, 2012, at 4:16 PM, David Levin <levin at chromium.org> wrote:
>>>
>>> Resurrecting a really old thread so continue the conversation now that I'm
>>> hitting this issue :).
>>>
>>> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>>>>
>>>> I am not sure I agree.  Does our behavior actually cause any real bugs in
>>>> the places you have tracked down?  The log spam really doesn't seem like an
>>>> issue, we can remove it if we want to, but have found it useful in the
>>>> past.
>>>
>>>
>>> Speaking as someone who working on a web app, the log spam is
>>> a significant issue because:
>>>
>>> It clutters up the console output making it harder to find the real error.
>>> (It is hard to explain how much worse this makes the experience until you
>>> have to deal with a sophisticated web page. Image looking at the logs from
>>> your app and seeing lots of error messages -- many of which are this one and
>>> then a real one hidden among them -- from personal experience.)
>>> When more sophisticated end users see it, they think there is a problem in
>>> the app and report it (and it could be that they include this in their error
>>> report and ignore other more important things).
>>>
>>> I understand that that the console/log spam is useful to detect real
>>> issues as well (given that WebKit doesn't throw an exception in this case).
>>>
>>> Would people find it acceptable to have window.webkitCanAccess so that a
>>> web page can use that property first to detect the cross origin issue and
>>> avoid doing an access which would trigger the console spam? (I would also be
>>> fine with an exception instead of log spam.)
>>>
>>> Thanks,
>>> dave
>>>
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>