Bug 73359 – Move postMessage origin check to SecurityOrigin

• Status: RESOLVED
• Resolution: WONTFIX
• Component: UI Events

[Karl Koscher]

As explained in bug 73337, we need the ability to create frames that accept postMessages intended for any origin. Moving the postMessage origin check from DOMWindow to SecurityOrigin lets us specify that a document has a special SecurityOrigin with the privilege to do so. We also need to call this check from Chromium before we dispatch a postMessage to a WebFrame.

[Karl Koscher]

Created attachment 117065 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail] before submitting because this patch contains changes to the Chromium public API.

[Darin Fisher (:fishd, Google)]

+abarth, who should review all SecurityOrigin changes.

[Sam Weinig]

Comment on attachment 117065 [details]
Patch

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

> Source/WebCore/page/DOMWindow.cpp:913
>          // Check target origin now since the target document may have changed since the simer was scheduled.

Might want to fix the typo, simer -> timer, while you are here.

[Adam Barth]

Comment on attachment 117065 [details]
Patch

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

> Source/WebCore/page/SecurityOrigin.h:103
> +    bool canReceivePostMessage(const SecurityOrigin* intendedOrigin);

Maybe canReceivePostMessage => canReceiveMessagesFor ?  You want to be clear that it's "for" the intendedOrigin rather than "from" a source origin, even at the call sites.

> Source/WebCore/page/SecurityOrigin.h:113
> +    // Explicitly grant the ability to receive postMessages from any origin.
> +    void grantReceivePostMessagesFromAnyOrigin();

Can you explain when we'd want to grant this privilege?

[Karl Koscher]

Created attachment 117489 [details]
Updated patch

(In reply to comment #5)
> (From update of attachment 117065 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=117065&action=review
> 
> > Source/WebCore/page/SecurityOrigin.h:103
> > +    bool canReceivePostMessage(const SecurityOrigin* intendedOrigin);
> 
> Maybe canReceivePostMessage => canReceiveMessagesFor ?  You want to be clear that it's "for" the intendedOrigin rather than "from" a source origin, even at the call sites.

Yeah. I was confused a bit myself, but cleaned that all up.

> > Source/WebCore/page/SecurityOrigin.h:113
> > +    // Explicitly grant the ability to receive postMessages from any origin.
> > +    void grantReceivePostMessagesFromAnyOrigin();
> 
> Can you explain when we'd want to grant this privilege?

I'm working on getting cross-process postMessages to work. The way we're doing it is by installing a native event listener from the chromium side on a blank, swapped-out document. However, since this document doesn't have an origin, it needs to be able to receive messages intended for any origin. We then call canReceiveMessagesFor from the chromium side right before we dispatch the message. This prevents a race where the origin could change between the time it was checked and the time it was dispatched (which is why we can't simply set the proxy document's origin).

[Adam Barth]

Hum...  That doesn't sound like the most elegant design.  Why not have postMessage ask the embedder if it would like to deliver the message instead?  The embedder would then signal that it will deliver the message before we run the security check.

[Karl Koscher]

(In reply to comment #7)
> Hum...  That doesn't sound like the most elegant design.  Why not have postMessage ask the embedder if it would like to deliver the message instead?  The embedder would then signal that it will deliver the message before we run the security check.

This was Darin's suggestion, but I agree that it doesn't seem too elegant. I'll look into this approach.

[Karl Koscher]

(In reply to comment #7)
> Hum...  That doesn't sound like the most elegant design.  Why not have postMessage ask the embedder if it would like to deliver the message instead?  The embedder would then signal that it will deliver the message before we run the security check.

Do you have any opinions on where this interface should be added? WebFrameClient seems like a logical choice, but then we'd need to thread it through FrameLoader and FrameLoaderClient. I'm not sure how much sense that would make. WebViewClient is another option, but it would also needed to be threaded through some unexpected classes (Page, Chrome, ChromeClient). As an alternative, we could add a new client to Page, but that seems like overkill. Thoughts?

[Adam Barth]

WebFrameClient is the correct place.  There are some layers to drill through, but it shouldn't be too bad.

[Karl Koscher]

We're now going to ask the embedder if it wants to deliver the postMessage, making this bug obsolete.