Re: Online Accounts panel for 3.2

On 04/27/2011 07:01 PM, David Zeuthen wrote:
>> 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.

Yes, if you have service plugins or configuration files you could
specify whether the OAuth callback should be a local webserver or a
normal web page, and then have your own browser widget.

> 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.

It's not so bad. The problem is if this authentication needs to be
periodically renewed; in such cases, the possibility to run a browser
widget would be very appreciated by the users (it might be that it's
even possible to keep the web UI invisible, if it shares the same
cookies as the user's browser and the re-authentication doesn't require
user interaction -- but it's something that just crossed my mind, I'm
not suggesting it :-) ).

> (Btw, we could also have something like a
> 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 is really something I want to avoid
> - it sounds like a disaster in the making.)

It also depends on what credentials are being passed to the callback
URL; in most cases I would expect it to be a temporary secret token, so
it might not be that bad either. Though of course, I'd keep it as the
very last option.


-- <- geek in un lingua international!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]