[whatwg] postMessage's target origin argument can be a full URL in some implementations
bzbarsky at MIT.EDU
Mon Jul 19 08:38:40 PDT 2010
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:
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
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.
More information about the whatwg