Re: Online Accounts panel for 3.2

[Ross Burton <ross burtonini com>]

On 27 April 2011 14:18, David Zeuthen <zeuthen gmail com> wrote:
> We probably want to embed a web browser engine for the Online Accounts
> panel - e.g. I don't think it's not good enough to rely on the users
> browser with the way e.g. OAuth2 works -- you really want to intercept
> the redirect URL and not have to scrape the authorization code out of
> a window title (as the Google OAuth2 docs humorously suggests) or have
> the user copy/paste it to the panel. In this case we want to use
> WebkitGTK+ which has
> WebKitWebView::navigation-policy-decision-requested signal to solve
> this.

Some services such as Fire Eagle recommend that you use the default web
browser and don't embed a HTML widget on the grounds that the user will then
see the URL and other security information that they are used to, and not
just random HTML that could well be faked.  They then recommend to redirect
back to the application by registering a new URL protocol (say,
x-myapp-auth) and redirecting there.

These rationales seemed really sensible so we tried this in MeeGo and
discovered that Fire Eagle is the only service we found who doesn't mandate
that the redirect URL is "valid", meaning a http: URL.  Some even refused to
redirect to localhost after the settings app started a private HTTP server
on the loopback interface.

So yes, I'd say that embedding a HTML engine is fairly important.  Being
able to support the user's own browser is probably a good idea too though.

Ross