[whatwg] Cross-domain components
ian at hixie.ch
Wed Aug 8 17:05:32 PDT 2007
On Sun, 29 Apr 2007, Henrik Gulbrandsen wrote:
> On Sat, 2007-04-28 at 02:43 +0000, Ian Hickson wrote:
> > >
> > > This could work for a single widget service, but breaks down if we
> > > imagine multiple popular components of this type that should follow
> > > a user's preferences even when surfing from a cybercafé
> > This could work, you just need the original iframe to show a login
> > page instead of the widget, and then once the user has logged in, use
> > the preferred widget.
> The keyword here is "multiple". I was imagining a scenario where this
> kind of integration becomes popular, and the user has not only the given
> calendar widget, but also an email launcher, a spreadsheet manipulation
> widget, a website preference negotiation component, a payment service
> provider widget, and a context-sensitive application toolbar integrated
> with the main menu of a given site.
> All of these might not be used on a single site, but it would still be
> very annoying to have a separate login for each and every component.
> That is why I mentioned the "global login" option in my original post.
> With a single login per browser session, this generalized mashup would
> actually scale; it's also useful as a general cross-site login method.
I agree, but this doesn't have to be implemented in the spec. Distributed
decentralised single sign-on is addressed by things like OpenID. The
system described above, with iframes pointing at widget meta-providers and
having them redirect to widgets after login can still be done with a
single login step without further help from the spec.
> One way to do this would be to have a URI-Specific Profile ID that acts
> as the combined username/password secret for a specific web resource.
> Let's say that the client looks for a string like "(*URISPID*)" in all
> loaded URLs. If the string is found, it is replaced with an MD5 hash of
> a local user secret (username/password) combined with a part of the URL.
> If the client doesn't support this feature, the "(*URISPID*)" part is
> left unchanged, so the server can fall back to a traditional login page.
> For example, an access to
> could have its "(*URISPID*)" part replaced by
> hash(hash(username + ":" + password) + ":" + base_url)
> where base_url = "https://www.example.com/interfaces/calendar/v1".
That's possible, but I think it's better to decouple the solution from
the HTML5 language here, in the manner of OpenID and others. We want to
provide a platform on top of which this kind of thing can be built.
> > > Item 3 highlights a privacy leak in the cross-document messaging API
> > > specified in the current WA1 draft. It's clear that postMessage()
> > > was not intended for this kind of scenario, since the domain
> > > attribute will completely break any attempt to hide the two domains
> > > from each other.
> > Hm, interesting. It's true that the current design leaks the domain.
> > You could get around that by having messages proxied through the
> > original redirecting domain, though; no privacy leak there since the
> > original domain is know to the embedding page and the chose widget
> > provider has to be known to the middleman already.
> Well, in principle you don't want those messages to be exposed to the
> redirecting domain either, but I suppose that the interface publisher is
> more trusted than the other domains. Since the interface is central, any
> attempt to pass private data back to the server would be noticed quickly
> by someone. Besides, if the redirecting domain isn't trusted, it can use
> the proxy iframe anyway, although we are actually expecting a redirect.
> This means that your workaround is most likely acceptable for this case,
> although I'm slightly worried that it might not cover other scenarios.
> In general, it's probably safer if the author must request to have the
> domain visible when it should be checked, rather than the other way
> around, since he may not remember to hide it when that is needed.
> However, I don't feel strongly about this, since I don't know if domain
> hiding will ever be strictly necessary. Let's just keep it in mind, so
> we don't make this hole in the same-origin policy bigger than it needs
> to be. Perhaps a hide/show flag argument to postMessage() is worth the
> extra trouble, just to stay on the safe side.
It's something to bear in mind if there's a need, I agree. I don't think
we need it in the first version, though.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg