[whatwg] postMessage's target origin argument can be a full URL in some implementations

On 7/19/10 8:56 AM, Hallvord R M Steen wrote:
> I have no idea when other implementations of postMessage() were
> written. However, "throw an exception if targetOrigin has a
> path/query/fragment" is a spec requirement since October 2008
> according to this change:
> http://html5.org/tools/web-apps-tracker?from=2353&to=2354

Gecko's support for postMessage landed in late January 2008.  It was 
updated to the changes to add the origin stuff in late February 2008.

> I agree with that in general, however it makes things harder that this
> is an issue that might have security implications.

The security implication being that authors might get confused about 
what the origin actually means and whom they can expect messages from, 
right?  Or did I misunderstand your original post?

> Facebook uses it in a "clever" way to actually pass on some GUID/data
> in the path, which will presumably appear in e.origin in the message
> listener?

e.origin is the origin the event originated at.  It's computed by the 
browser, and is entirely independent of the arguments passed to 
postMessage.  In Gecko's case, this is computed using the "compute an 
origin" URI in the HTML5 spec.

The only thing the string passed to postMessage is used for is 
same-origin comparisons when deciding whether to deliver the event at 
all.  And of course same-origin comparisons don't depend on the path 
portion of the url; I would expect every single web developer who knows 
what a same-origin comparison is to know that...

In fact, internally Gecko strips off the path (and username and 
password) from the string passed in to postMessage before storing it.

-Boris

Received on Monday, 19 July 2010 08:38:40 UTC