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. Ross _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
