- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Tue, 16 Dec 2008 18:16:20 +0100
About the cross-document messaging
Let's consider the following scenario. A somewhat productivity suite (or
any sort of "web applications collection") is made up of a few different
top-level/auxiliary browsing contexts - let's call each one a "module" -
eventually from different origins, and exploits cross-document
communications to some extent, i.e. to delegate some computations or
some shareable communications with a remote server; each module is
independent and can instantiate the proper auxiliary module(s).
Here we are: as far as the modules are instantiated as auxiliary
browsing contexts of one other module (i.e. through a call to
'window.open()'), communications are easily established, but what if any
module is instantiated by the user as a separate top-level browsing
context, i.e. opening a new tab or window and recalling the module
document from a bookmark? I'd suggest the following:
- a mechanism is established to get access, without any restriction, to
every browsing context for which the user agent can individuate a
non-empty, non-null, non-undefined name attribute, at least with the
capability to let "cross-origin" access to the postMessage() methods.
For instance, the specifications could clearly state that the Window
open() method must return an existing window reference with the
specified name when invoked with an empty string or null as URL
argument, with no security restriction (security restrictions should
apply just to the returned window object properties). When more than one
browsing context share the same name, actual "rules for choosing a
browsing context given a browsing context name" should apply to choose a
first result, without checking if current browsing context is allowed to
navigate that browsing context; it might be helpful to get instead a
list of all browsing contexts with the same name, obtained as follow: a
Window object is created as a pseudo unit of browsing contexts, so that
each browsing context is reachable both by invoking the XXX4() method
and by accessing the frames property; each browsing context is wrapped
in a Window object with 1)accessible postMessage() methods, calling the
wrapped window ones, 2)an accessible parent attribute referring to the
grouping Window object, 3)a self attribute referring to the wrapped
object, accessible if access to the wrapped object is allowed by
security restrictions, 4) access denied, without any exception/error
arising, to any other method/attribute; the first member of the group
(i.e. the object returned by calling XXX4(0) on the grouping Window) is
the wrapper for a Window object determined by the rules for choosing a
browsing context given a browsing context name (i.e. the most recently
opened, or focused, or the most related with the open() method caller
browsing context) and is returned.
- optionally, a few "postMessageToAll()" methods (with about the same
arguments of the postMessage() ones) could be considered to let any
browsing context to communicate, through its own Window interface,
either to any other browsing context (eventually allowing communications
from current browsing context as source, see below), or to every
browsing contexts constrained by the same name (passed as, let's say,
first argument), or to every browsing contexts with the same domain
(specified, let's say, as the second argument).
Let's consider another scenario. A site (perhaps a blog) embeds content
from a forum (or any social network), and uses script code to connect to
the remote server and keep it's content up to date, but also to notify
the user about any changes in other contents the remote server holds as
subscribed (this scenario can be extended to mail notifications in the
previous example of a productivity suite, or to a groupware). When the
user navigates other documents from the site in different browsing
contexts, each one is aware of the others (perhaps establishing a
connection through a call to postMessageToAll, or by getting a reference
by name); to avoid increasing the number of connections per server, any
successive document navigated as a standalone browsing context (after
the first or after a certain number) won't connect to the remote server,
but will communicate with the document having an active remote
connection. That is: the first navigated document maintains a remote
connection and receives notifications as remote events; if it is fully
active, the notifications are shown to the user, otherwise a message is
sent to any other known document capable to handle the notification,
hoping one is fully active; the first document becoming fully active
handles the messages and notifies to the other documents that any
required operation has been performed; when the remote events handling
document(s) are to become no more active (i.e. they unload), a message
is sent to the remaining documents so they can decide (somehow) who's
the next "dispatcher".
The above could be realized with a few eventsource elements in the
documents, each one with a proper list of event sources and one or more
MessageEvent listeners on the corresponding Window object, which could
"manually" handle the switching operations (i.e. calling the appropriate
element's addEventSource()/removeEventSource() and creating the
appropriate event to dispatch to the eventsource listeners from the
received messages); however, most of the work could be automated in the
following manner:
- let the MessageEvent instances hold one attribute for the remote event
URL and one for the remote event type;
- let's provide appropriate methods to set those attributes and to post
a message constrained this way (a pair of initMessageEvent and
postMessageEvent variant should be enough);
- let the RemoteEventTarget list of event sources hold, for each source,
an attribute (to be set when adding a source and optionally referred to
on removal) identifying one of three state: remote-only, for exclusively
remote messaging; local-only, for cross-document messaging (mainly
thought for Window objects, optionally for other elements); both-sides
to handle a scenario like the above described one; a proper attribute
could be thought for eventsource elements, such to be coupled with the
src attribute;
- let Window objects have a default action for message events,
inspecting the event for remote url and event type and, if found,
forwarding the event - with proper modification, or creating a new
appropriate event - to each RemoteEventTarget waiting for that remote
source, with a "both" state, present in the active document; optionally
a non remote cross-document message could be considered to be dispatched
to the active document RemoteEventTargets waiting for cross-document
messages (see below);
- optionally, for security aim, it could be established that before
accepting a remote event dispatched as a cross-document event, a
connection is made to the remote source to get a session id as the first
streamed event data, which must match the cross-document message data
(the remote events originating server should be capable to identify the
user instantiating the communication through different
documents/browsing-contexts, i.e. by the mean of a log-in procedure,
session-ids, cookies, or a combination of those methods, and so generate
and send the same "session-communication-id");
Listing an expected source of cross-document events as a remote source
(that is taking advantage of the RemoteEventTarget interface), specially
on Window objects, could be helpful to improve cross-document security,
since posting a message would fail not only if the recipient origin does
not match the message targetOrigin, but also if the message origin is
not registered as a valid source; anyway, the possibility to get
messages from any other Window should be preserved availing the
registration of the string "*" (this should be the default value of a
default source if no source is registered, with a state of "both"; when
the first source is registered the default source is removed; if the "*"
string is added to a list comprehending valid absolute URLs, the state
should discriminate the acceptance of a message - i.e. a simple
cross-document message is accepted from any source while a
cross-document message "enveloping" a remote event is accepted from just
one source, and dispatched if an eventsource is waiting from messages
from such source).
Furthermore, the EventListener interface could be derived to give the
opportunity to list all sources a listener is able to handle, as tuples
consisting of: 1)the expected target origin (either the listener owner
document origin, or "*"), 2)the expected source origin (the event origin
attribute), 3) the expected remote source origin (for remote events
dispatched as cross-document messages), 4)the accepted state; all 4
components of the tuple could be optional (but not missing: null or the
empty string should be valid values), but at least one of the first
three should not be neither null nor the empty string, otherwise the
whole tuple should be ignored (and discarded from the list); if the
state component is not expressed, it should default to the value of
"both" (this being either a string or a numerical value, accessible as a
constant: to be defined); if no tuple is listed, a default tuple is
created with the components: ("*","*","*",<both_value>); the tuple
("","","http://example.server.src",<remote_only_value>) should accept
events just from the indicated remote server, while the tuple
("","","http://example.server.src",<both_value>) should be treated as if
the first two components were equals to "*", meaning any remote event
originating at "http://example.server.src" can be accepted as a
cross-document re-dispatched one, and the tuple
("","","http://example.server.src",<local_only_value>) should be illegal
(as if the 3rd component where "" or null); if the state component is
"remote-only" the first two components, if expressed, should be ignored
(or the second be legal only if matching the third, since we are dealing
with remote events accepted just from the remote server), if it is
"local-only" the 3rd component should be ignored (and deemed as
mistaken, but without entering an error state, since the user agent
should never dispatch cross-document re-dispatched remote events to a
listener waiting for "local-only" cross-document messages, despite the
remote component of the tuple ??? that is, the third one ??? otherwise that
should be deemed as illegal), while if it is "both" the 3rd component,
if not expressed should be defaulted to the string "*".
The tuples list on a message listener should simplify the URLs checking
inside the listener (which could be thought to make the same operations
consistently in different contexts, so no checking could be needed at
all), and thus improving the overall security. In such an environment a
cross-document message is delivered if and only if: a) the target origin
matches the document domain or is the "*" string, and b) the message
origin is listed as remote source for the Window object (or is expressly
allowed by the "*" string), and c) a listener is actually waiting a
message of that type from that source and with the corresponding
connection state (either "local-only" or "both"); a remote (streamed)
event is delivered if: a) the event source is registered to a
RemoteEventTarget, and b) a listener on such RemoteEventTarget is
actually waiting for an event of that type from the same source. This
should also enable a precise listener selection.
Allowing a RemoteEventTarget inside a document to list a source as
"local-only" and receive messages from other documents instead of remote
servers (through out a default action defined for Window objects
receiving messages, which could not handle it directly) could be an
alternative (and to some extent a redundant) way to allow cross-document
messaging at a Document level instead of a browsing context level, maybe
suitable for some scenarios (or maybe just desirable, as far as a
certain grade of redundancy in an API might be desirable). A
"originForResponse" and a "sourceForResponse" attributes could be
considered, for the MessageEvent interface, in order to allow a certain
capability of syndication and communications distribution and switching
among collaborating documents (i.e. the listener checks for those
attributes and answers in a manner such as:
'event.sourceForResponce.postMessage(message_str,
event.originForResponse)' ??? the postMessage methods should accept two
arguments to set those attributes). If a post method were provided to
allow communications from a single source to any existing browsing
context (i.e. "postMessageToAll()"), the "targetOrigin" argument should
be absent and it should be clearly stated in the specs that such a
method must call the proper post method on each existing browsing
context, passing the proper URL as the targetOrigin argument.
Regards, Alex
--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
Sponsor:
CheBanca! La prima banca che ti d? gli interessi in anticipo.
* Fino al 4,70% sul Conto Deposito, zero spese e interessi subito. Aprilo!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8435&d=16-12
Received on Tuesday, 16 December 2008 09:16:20 UTC