On 9/25/2012 2:05 PM, Demian Brecht wrote:
This is a shameless plug, but if you want a much easier to understand method of accessing protected resources via OAuth2, I have a 55 LOC client implementation with docs and examples here:https://github.com/demianbrecht/sanction (Google is one of the tested providers with an access example).


No complaints from me if it works. Honestly I was a bit discouraged at Google's decent lack of documentation and the quality of the code.

Are you trying to access resources client side (through Javascript) or server side? Either way, the redirect URI *is* important. The first step is to have your user authorize your application using Google's authorization page. As one of the query parameters, you must specify the redirect URI (which must match those registered through Google's app console).

I'm trying to access it through a desktop Python application, which made me really confused. There was something else that talked about returning the tokens in a different way, but it talked about returning them in the title of the webpage, and since I'd be spawning a browser to request authorization, I'd have to write something that would pull the window information and then parse out the token from the title, which doesn't sound to stable.

Once the user has authorized your application, they're redirected back to your site (via the specified redirect URI), with a "code" attached as a query param. Once you get that code, you must exchange that with Google's token endpoint to retrieve the access and refresh tokens.

Awesome. I could theoretically just create a webpage on my server to redirect people to with the query, but I'm still not quite sure how I'd retrieve that from the desktop application.

No, it doesn't matter which library you use. Google's (imho) is overly verbose and difficult to grok (especially for someone new to either OAuth 2.0 or Python, or both). The client ID doesn't need to be kept private, but the secret does. You should *never* put this anywhere that can be read publicly.

I plan on storing them both in variables. It's not going to be the best solution, but I plan to use python -O to create pyo files, which from what I understand are harder to decompile, and it'll be in a py2exe executable. Still not to hard to get at, but it's not right there either.


On Tue, Sep 25, 2012 at 12:04 PM, Littlefield, Tyler <ty...@tysdomain.com <mailto:ty...@tysdomain.com>> wrote:

    Hello all:
    I've been trying  to figure out the oauth2client part of google's
    api, and I am really confused.
    It shows a flow, and even with the client flow, you need a
    redirect uri. This isn't important because I just want to get both
    an access and refresh token.
    Has anyone had any experience with this? Is it  easier to use a
    more developed oauth2 library to handle this? If so, can anyone
    make any suggestions?

    If I understand everything correctly, it doesn't matter what
    library I would use to work with the oauth2 protocol, so I could
    break out of this workflow thing that looks like it's more
    designed for web apps.
    Finally, they caution you about being careful about your client id
    and your client secret; is  there much in the way of obviscation
    or something I can do to keep this secret?

-- Take care,
    Ty
    http://tds-solutions.net
    The aspen project: a barebones light-weight mud engine:
    http://code.google.com/p/aspenmud
    He that will not reason is a bigot; he that cannot reason is a
    fool; he that dares not reason is a slave.

-- http://mail.python.org/mailman/listinfo/python-list




--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that 
dares not reason is a slave.

-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to