Bug 75155 – [chromium] Add isSameSchemeHostPort method to WebSecurityOrigin

• Component: WebKit API
• Status: RESOLVED WONTFIX

[Karl Koscher]

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.

[Karl Koscher]

Created attachment 120419 [details]
Patch

[WebKit Review Bot]

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

[Adam Barth]

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?

[Karl Koscher]

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.

[Adam Barth]

> 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.

[Adam Barth]

We'd probably add that on WebFrame since I don't think we have a notion of the DOMWindow in the API.

[Charles Reis]

We're now going to expose checkAndDispatchMessageEvent in bug 85815, making this bug obsolete.