Bug 51714 - Move security logic out of the JavaScript binding for location into the DOM class
Summary: Move security logic out of the JavaScript binding for location into the DOM c...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
Depends on:
Blocks: 51762
  Show dependency treegraph
 
Reported: 2010-12-29 10:16 PST by Darin Adler
Modified: 2010-12-30 12:50 PST (History)
4 users (show)

See Also:


Attachments
Patch (48.89 KB, patch)
2010-12-29 10:29 PST, Darin Adler
no flags Details | Formatted Diff | Diff
Patch (48.97 KB, patch)
2010-12-29 16:30 PST, Darin Adler
abarth: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2010-12-29 10:16:51 PST
Move security logic out of the JavaScript binding for location into the DOM class
Comment 1 Darin Adler 2010-12-29 10:29:40 PST
Created attachment 77630 [details]
Patch
Comment 2 WebKit Review Bot 2010-12-29 10:39:17 PST
Attachment 77630 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7255240
Comment 3 Darin Adler 2010-12-29 10:51:30 PST
Comment on attachment 77630 [details]
Patch

I'm taking down the patch so I can add the include and so fix the Chromium build (at least) and also investigate some regression test failures that indicate I made a small mistake somewhere.
Comment 4 Darin Adler 2010-12-29 10:52:08 PST
Adam, this is the work you recently suggested.
Comment 5 WebKit Review Bot 2010-12-29 11:39:06 PST
Attachment 77630 [details] did not build on chromium:
Build output: http://queues.webkit.org/results/7270232
Comment 6 Darin Adler 2010-12-29 16:30:13 PST
Created attachment 77651 [details]
Patch
Comment 7 Adam Barth 2010-12-29 21:18:40 PST
Comment on attachment 77651 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=77651&action=review

Very nice.  I've suggested some FIXME comments below.  It's amazing to me how much of this machinery was redundant.  Thanks for working on this code.  I'll follow up with the V8 change once this patch lands.

> WebCore/bindings/js/JSDOMBinding.cpp:701
>  Frame* toDynamicFrame(ExecState* exec)
>  {
> -    return JSBindingState(exec).firstFrame();
> +    return firstDOMWindow(exec)->frame();
>  }

We should probably rename this function to something involving "first" to be consistent with our new names.

> WebCore/bindings/js/JSDOMBinding.cpp:706
>  bool processingUserGesture()
>  {
> -    return JSBindingState(JSMainThreadExecState::currentState()).processingUserGesture();
> -}
> -
> -KURL completeURL(ExecState* exec, const String& relativeURL)
> -{
> -    JSBindingState state(exec);
> -    return completeURL(&state, relativeURL);
> +    return ScriptController::processingUserGesture();
>  }

We should probably inline this function into its call sites.

> WebCore/page/DOMWindow.cpp:1612
> -void DOMWindow::setLocation(const String& urlString, DOMWindow* activeWindow, DOMWindow* firstWindow)
> +void DOMWindow::setLocation(const String& urlString, DOMWindow* activeWindow, DOMWindow* firstWindow,
> +    SetLocationLocking locking)

A line break!  In WebKit!  :)

> WebCore/page/Location.cpp:262
> +    // FIXME: It's not clear this cross-origin security check is valuable.
> +    // We allow one page to change the location of another. Why block attempts to reload?
> +    // Other location operations simply block use of JavaScript URLs cross origin.

Maybe it has to do with re-POSTing form data?  The other location operations can only generate GET requests.
Comment 8 Darin Adler 2010-12-30 11:02:59 PST
(In reply to comment #7)
> > WebCore/bindings/js/JSDOMBinding.cpp:701
> >  Frame* toDynamicFrame(ExecState* exec)
> >  {
> > -    return JSBindingState(exec).firstFrame();
> > +    return firstDOMWindow(exec)->frame();
> >  }
> 
> We should probably rename this function to something involving "first" to be consistent with our new names.

My intention is to delete this entirely ASAP.

> > WebCore/bindings/js/JSDOMBinding.cpp:706
> >  bool processingUserGesture()
> >  {
> > -    return JSBindingState(JSMainThreadExecState::currentState()).processingUserGesture();
> > -}
> > -
> > -KURL completeURL(ExecState* exec, const String& relativeURL)
> > -{
> > -    JSBindingState state(exec);
> > -    return completeURL(&state, relativeURL);
> > +    return ScriptController::processingUserGesture();
> >  }
> 
> We should probably inline this function into its call sites.

The reason I didn't in this patch was concern over the header dependency on ScriptController.

> > WebCore/page/DOMWindow.cpp:1612
> > -void DOMWindow::setLocation(const String& urlString, DOMWindow* activeWindow, DOMWindow* firstWindow)
> > +void DOMWindow::setLocation(const String& urlString, DOMWindow* activeWindow, DOMWindow* firstWindow,
> > +    SetLocationLocking locking)
> 
> A line break!  In WebKit!  :)

LOL.

> > WebCore/page/Location.cpp:262
> > +    // FIXME: It's not clear this cross-origin security check is valuable.
> > +    // We allow one page to change the location of another. Why block attempts to reload?
> > +    // Other location operations simply block use of JavaScript URLs cross origin.
> 
> Maybe it has to do with re-POSTing form data?  The other location operations can only generate GET requests.

Interesting point.
Comment 9 Darin Adler 2010-12-30 11:29:17 PST
Committed r74800: <http://trac.webkit.org/changeset/74800>