chrome postMessage
John J Barton
written:
https://developer.mozilla.org/en/DOM/window.postMessage#Notes
I can't understand the section on using postMessage in chrome, other
than it's busted some how. Has anyone been successful with it?
jjb
Jonas Sicking
> On 6/8/11 3:30 PM, John J Barton wrote:
>>
>> I can't understand the section on using postMessage in chrome, other
>> than it's busted some how.
>
> server-hostname-based security model. Chrome does not use such a model, nor
> can it. Hence the origin aspects of postMessage do not work correctly in
> chrome.
>
> If you're willing to not rely on those aspects and just postMessage to '*'
> (so any target origin), it should work fine.
Though what's the need for using postMessage in chrome? postMessage
was designed to allow frames from different origins to safely talk to
each other. But chrome has no such issues and can just call whatever
function is needed across frames.
/ Jonas
johnjbarton
But frames cannot call functions on chrome. But my primary interest is
to fill in this diagram:
content <-> content postMessage w/json packets
chrome <-> content ??? w/json packets
chrome-process <-> content-process sendAsyncMessage w/json packets
browser <-> browser crossfire w/json packets
browser <-> eclipse crossfile w/json packets
The Orion service registry model layers nicely on top of such messaging
and it would provide a modernized JavaScript component model.
jjb
Jonas Sicking
I think for chrome <-> content postMessage won't work by default at
all since content shouldn't be able to interact with chrome objects by
default.
A better solution is to simply make chrome insert objects into the
content page and expose API using the __exposedProps__ API as
documented here:
https://developer.mozilla.org/en/XPConnect_wrappers
/ Jonas
Robert Kaiser
> chrome <-> content ??? w/json packets
> chrome-process <-> content-process sendAsyncMessage w/json packets
If I read bsmedberg's post correctly, the message manager should work no
matter if it's different processes or not, so I'd guess sendAsyncMessage
would work for both cases.
Robert Kaiser
--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)
smaug
Or you can dispatch events which contain some extra data.
CustomEvent interface might be useful.
-Olli
>
> / Jonas
smaug
> johnjbarton schrieb:
>> chrome <-> content ??? w/json packets
>> chrome-process <-> content-process sendAsyncMessage w/json packets
>
> If I read bsmedberg's post correctly, the message manager should work no
> matter if it's different processes or not, so I'd guess sendAsyncMessage
> would work for both cases.
>
> Robert Kaiser
>
content can't use message manager. The TabChildGlobal in the content
process (which is essentially the chrome part of content process) can
use sendAsyncMessage/sendSyncMessage.
-Olli
Robert Kaiser
> content can't use message manager. The TabChildGlobal in the content
> process (which is essentially the chrome part of content process) can
> use sendAsyncMessage/sendSyncMessage.
Erm, OK, yes. Things are so complicated when needing to care about
potentially insecure content. Can we just not do content at all? ;-)
johnjbarton
Yes, that's true for all of these combinations.
>
> A better solution is to simply make chrome insert objects into the
> content page and expose API using the __exposedProps__ API as
> documented here:
>
> https://developer.mozilla.org/en/XPConnect_wrappers
Firebug uses this technique currently for its window.console. I'm unsure
if it will work in future and I'd like to have fewer technology
variables to maintain.
jjb
>
> / Jonas
johnjbarton
My current scheme uses documentElement.setUserData(key, json) and a
generic event to trigger reads of documentElement.getUserData(key).
> CustomEvent interface might be useful.
Thanks, but that appears to be C++ based:
https://developer.mozilla.org/en/Creating_Custom_Events_That_Can_Pass_Data
jjb
Jonas Sicking
I think __exposedProps__ is the fewer technology you are looking for.
Out of all the methods of communication you list above,
content<->chrome is the only one that is between trusted and untrusted
code. Hence it makes sense to have an API which is geared towards
being designed to be secure.
Instead I would try to reduce the other communicates methods.
/ Jonas
Jonas Sicking
> Out of all the methods of communication you list above,
> content<->chrome is the only one that is between trusted and untrusted
> code. Hence it makes sense to have an API which is geared towards
> being designed to be secure.
>
> Instead I would try to reduce the other communicates methods.
Another reason it makes sense for that one to be different is that
it's the only one that is in-process. (content<->content might in the
future not always be).
/ Jonas
John J Barton
Sorry I wasn't clear: we need to deal with all of these cases, it's not
a set of choices.
content <-> content firebug html front end <-> orion
chrome <-> content firebug xul front end <-> orion
chrome process <-> content process firebug loader <-> firebug backend
browser <-> browser firebug html front end <-> firebug backend
The content<->chrome piece is only helpful until we have the firebug
html front end. I was hoping to make the message layer for this piece
close to the one we use later.
(I expect we will continue to use __exposedProps__ between content
process and content like we do now between chrome and content.)
> Out of all the methods of communication you list above,
> content<->chrome is the only one that is between trusted and untrusted
> code. Hence it makes sense to have an API which is geared towards
> being designed to be secure.
Mostly the use case is trusted to trusted here. There are security
issues, such a verifying that the content you think you are talking to
is the content you are talking to and issues about opening a port that
can be exploited. The __exposedProps__ solution won't help us with these
problem unfortunately.
jjb
Jonas Sicking
I still don't think I'm fully understanding you, but note that you can
use __exposedProps__ to expose API to a webpage, and then make the
implementation of that API use sendAsyncMessage to talk to firebug or
anything else.
/ Jonas
johnjbarton
> On Thu, Jun 9, 2011 at 2:46 PM, John J Barton
>
> I still don't think I'm fully understanding you, but note that you can
> use __exposedProps__ to expose API to a webpage, and then make the
> implementation of that API use sendAsyncMessage to talk to firebug or
> anything else.
That would describe how Firebug's console would work: Firebug's
content-script would use __exposedProps__ to offer window.console. The
implementation would form json packets for the remote UI. (Hopefully
directly over the socket not sendAsyncMessage then socket).
But the other things we need to accomplish are talking to web pages over
postMessage (because that is the protocol), talk to remote components
(mobile, IDEs), and find a sane migration path. The first two are json
based: chrome postMessage would allow our current code to begin to work
like it must later.
Maybe I can use __exposedProps__ to fix window.postMessage ?
I find it confusing that __exposedProps__ can be secure, but the
postMessage docs say:
window.postMessage is available to JavaScript running in chrome code
(e.g. in extensions and privileged code), but the source property of
the dispatched event is always null as a security restriction.
How can an extension securely offer a property (via __exposedProps__)
but the browser itself cannot?
If the chrome window uses:
contentWin.postMessage(message, getOrigin(contentWin));
and the resulting source property was an object with postMessage(), then
the contentWin can reply:
source.postMessage(reply, "*");
We don't need to worry about the chrome window navigating to a malicious
site. On the reply we can check source === contentWin so we know that
only our correspondent replied. I don't know if the contentWin gets a
useful value for targetOrigin in this scenario and I don't know if
source === null is a reliable test for "comes from chrome".
jjb
smaug
CustomEvent is not C++ only.
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMCustomEvent.idl
Or if you have to support also older Fx, there is non-standard
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMDataContainerEvent.idl
>
> jjb