Simple question re:subsequent token use

[Lindsey Simon]

I feel like I've been pecking around in code and docs like a moron so I'm just going to ask on the list ;)

So I have auth working nicely. =)

But I want to recall the method to re-reread a user's foo_user_info periodically (say every other day, just to keep in sync - assuming the user remains logged in).

In particular I just want to use the _oauth2_request method to make an arbitrary api request on google.

But I can't figure out how to re-gather up the auth_info and the user's token.

Should I just query the UserToken model with the user as parent ala:

webapp2_extras.appengine.auth.models.UserToken.query(parent=user.key).get().token ?

I feel like I might be missing something really simple.

My ultimate use case is that I actually want to query a totally different google API and figure I can smurf _oauth_request to do so ;0

Thanks for any insights!

[Lindsey Simon]

I can imagine that I could stuff auth_info into my session too, but I don't really want to do that.. I just want to re-retrieve the auth token to use on another API request - I see it sitting there in the UserToken model!

[Lindsey Simon]

hrm, so that token in UserToken isn't really what I need to make this subsequent API request. I need the auth_info['access_token']... Does the system store that bad boy anywhere or do I just need to implement that meself?

[Lindsey Simon]

ah, and it looks like (at least for google) the oauth2_init needs to include 'access_type': 'offline', in the params in order to obtain a refresh_token so that I can re-get an access_token on a user's behalf once it expires.

Oh joy - ok, I think I'm realizing I'm out of use-scope for simpleauth ;0

[alex]

Hey Lindsey,

just read all of your messages :)

Yeah, access_type is somewhat Google-related and simpleauth was meant
to serve as a login-only but I realize things change. For instance,
here's someone else looking to sort of force users to re-authenticate
on facebook: https://groups.google.com/d/msg/gae-simpleauth/Dr4-FMJzpS8/MC8wve734W0J

I was thinking, maybe we could add a little feature to be able to
inject optional extra parameters (an orbitrary dict):
https://github.com/crhym3/simpleauth/blob/84620d3db5670a20108d14d5021a42b69020c1e8/simpleauth/handler.py#L179

What do you think?

> --
> You received this message because you are subscribed to the Google Groups
> "SimpleAuth for GAE" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gae-simpleaut...@googlegroups.com.
> Visit this group at http://groups.google.com/group/gae-simpleauth.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Lindsey Simon]

Hey Alex,

Yeah, I think being able to set up an arbitrary dict may turn out to be handy.

I don't see anything in the link you sent that does that on line 179.. but that idea sounds good to me. =)

[alex]

Ah, sorry. That link should point to where params for oauth2 init are currently setup:

  params = {
    'response_type': 'code',
    'client_id': key,
    'redirect_uri': callback_url
  }

I think it should be as simple as:

  params.update(extra_params)

where extra_params could be {'access_type': 'offline'} for Google

or {'auth_type': 'reauthenticate'} for Facebook,

or anything else for any provider.

Do you maybe have time to work on this?

Otherwise, I should be able to figure it out next week (not sure about the weekend, but... maybe).

[Lindsey Simon]

On Fri, Jun 28, 2013 at 3:53 PM, alex <al...@cloudware.it> wrote:

Ah, sorry. That link should point to where params for oauth2 init are currently setup:

  params = {
    'response_type': 'code',
    'client_id': key,
    'redirect_uri': callback_url
  }

I think it should be as simple as:

  params.update(extra_params)

Would extra_params just be a 4th item in the config list? (I think that's the best way for now)

Yep, I think so too. I guess I wonder if it wouldn't be cleaner to make each provider config just a dictionary instead of a list?

I find the tuples to be kind of unreadable and they don't extend nicely..

But of course, yeah, that would be a breaking change ;0

[alex]

Yes, I guess config is the right place. One thing probably to keep in
mind is that it should support a case where no extra params are
defined.

Sorry about tuples :) To be honest, I didn't like them either after all.
But, we could transition it to a dictionary w/o breaking: support both
dict and list configs and then maybe drop the list at some point.

If you want and have some time to work on this with a dict-config, I
think I could then make it work backward compatible with a list
config.