Re: Online Accounts panel for 3.2

[David Zeuthen <zeuthen gmail com>]

Hi,

On Wed, Apr 27, 2011 at 10:07 AM, Ross Burton <ross burtonini com> wrote:
> 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.

Yeah, I want to make this possible, on a per-service basis, as well.
It might include having the Online Accounts showing something like
this

 Paste the code from your browser here: [____________]

in the "Add Account" workflow... which is a little annoying but, I guess, OK.

(Btw, we could also have something like a
https://www.gnome.org/goa-aoauth-redirector web service that could be
used as the redirect_url. This web service would then be used to
transfer the authorization_code back to the desktop client (the
desktop client would register with that web service beforehand and use
the state= parameter to identify the callback). But having user
credentials flow through gnome.org is really something I want to avoid
- it sounds like a disaster in the making.)

    David