To support cross-process postMessage (bug 73337), we need to perform an origin check in Chromium. WebKit does the same check by calling SecurityOrigin::isSameSchemeHostPort. So, we need a way to call this function from Chromium.
Created attachment 120419 [details] Patch
Please wait for approval from fishd@chromium.org before submitting because this patch contains changes to the Chromium public API.
Comment on attachment 120419 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=120419&action=review > Source/WebKit/chromium/public/WebSecurityOrigin.h:96 > + // Returns true if this origin matches the other's scheme, host, and port > + WEBKIT_EXPORT bool isSameSchemeHostPort(const WebSecurityOrigin&) const; Hum... I can understand why you wrote this patch, but it makes me somewhat sad. isSameSchemeHostPort is a tempting function to call, but it's almost aways wrong. Is there some way we can do this access check inside of WebKit or WebCore instead of exposing this sandtrap to the embedder?
Comment on attachment 120419 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=120419&action=review >> Source/WebKit/chromium/public/WebSecurityOrigin.h:96 >> + WEBKIT_EXPORT bool isSameSchemeHostPort(const WebSecurityOrigin&) const; > > Hum... I can understand why you wrote this patch, but it makes me somewhat sad. isSameSchemeHostPort is a tempting function to call, but it's almost aways wrong. Is there some way we can do this access check inside of WebKit or WebCore instead of exposing this sandtrap to the embedder? We could move this check into SecurityOrigin, which is what bug 73359 did. However, we wouldn't need to add grantReceivePostMessagesFromAnyOrigin(). Alternatively, we could add an API to call DOMWindow::postMessage instead of just injecting the event.
> Alternatively, we could add an API to call DOMWindow::postMessage instead of just injecting the event. That's probably the best choice. It seems like an API that other code might want to call as well.
We'd probably add that on WebFrame since I don't think we have a notion of the DOMWindow in the API.
We're now going to expose checkAndDispatchMessageEvent in bug 85815, making this bug obsolete.