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
