[whatwg] A few hints on html5 - part 3

[Calogero Alex Baldacchino]

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