Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
Sender: kushal.kumaran@gmail.com
In-Reply-To: <CAE+T62YMo1wCoM+OQco9-v_D0hjR92E3UDMg7FQYVePdyDUfag@mail.gmail.com>
References: <5062003A.9020208@tysdomain.com> <CAE+T62YBAaJquh4LnoAXwBTAj-jk3+4gEn6g8Zq_tbYuuZ9_NQ@mail.gmail.com> <50621279.8060700@tysdomain.com> <CAH8GtdN1ZF8m2L+S9fRwjv4oChurDPYCm-jwaBM4DVC3J_jodw@mail.gmail.com> <CAE+T62YMo1wCoM+OQco9-v_D0hjR92E3UDMg7FQYVePdyDUfag@mail.gmail.com>
From: Kushal Kumaran <kushal.kumaran+python@gmail.com>
Date: Wed, 26 Sep 2012 13:54:17 +0530
Subject: Re: google api and oauth2
To: Demian Brecht <demianbrecht@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1404.1348647883.27098.python-list@python.org>
Lines: 49
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:30161

On Wed, Sep 26, 2012 at 11:45 AM, Demian Brecht <demianbrecht@gmail.com> wrote:
>>
>> If you are writing a desktop application, read this:
>> https://developers.google.com/accounts/docs/OAuth2#clientside
>
>
> You mean https://developers.google.com/accounts/docs/OAuth2#installed? Your
> link discusses client side browser implementations.
>

Ah yes, I made a mistake in linking displayed url and scrolled position.

> I'd be curious to know the shortcomings of sanction in the context of
> installed apps. My original intent was to provide a server flow
> implementation. If the installed flow isn't too much of a change (doesn't
> seem like it would be, according to the docs, it's how the "code" is
> retrieved by the application), I'd happily add it in or take a patch to
> cover it.

I tried out sanction from a python shell.  In an installed
application, the user can either start a little web server to handle
redirect_uri, or pass in the special value "urn:ietf:wg:oauth:2.0:oob"
to have the authorization code be shown in a text field in the browser
(all of this is for google, I have no idea how other implementations
or the oauth spec differ).

At the moment, the auth_uri function gives out a URI and leaves it up
to the client to deal with it however it likes.  The library could
provide a function (let's call it drive_auth) to drive the entire
process: start a little web server on any available port, give a url
to that server as redirect_uri, then start the user's web browser to
connect to the authentication endpoint.

The embedded web server will need to handle redirect_uri to grab the
authorization code, generate an HTML response that will close the
browser window (or instruct the user to do so), and then stop itself.

For GUI applications which can embed a web browser widget, there is no
need to start a separate web browser application.  To support such
applications, the drive_auth function can take a callback argument to
navigate to a particular URL.  Then the client applications can hook
in their particular GUI toolkit, or just pass in webbrowser.open if
they like.

All this may be beyond the intended scope of your library.

-- 
regards,
kushal