Hi, On Wed, Apr 27, 2011 at 10:07 AM, Ross Burton <[email protected]> wrote: > On 27 April 2011 14:18, David Zeuthen <[email protected]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
