如何在GAE / Python上进行“ access_type = offline” /仅服务器的OAuth2操作?
问题内容:
这篇文章是 如何在GAE
cron工作中执行需要OAuth的操作
的后续文章
?
,我意识到自己在滥用的@oauth_required
装饰器OAuth2DecoratorFromClientSecrets
。
如OAuth 2.0解释的演示文稿所述,Oauth 2.0解决了以下问题:
- 建立 服务…
- …由 用户 访问…
- … 并从第三方访问用户的数据 。
那就是@oauth_required
抽象的内容,并且很好地完成了(当前我的应用程序“正常运行”:如果我触发刷新页面,则要求我向我的应用程序授权对我的youtube数据的访问权,其余的则紧随其后)。但这不是我想要的!我的应用程序做得更简单,每天使用
我的 凭据创建YouTube播放列表, 而无需任何用户输入 。因此,与上述三层谈判相比,我想要:
- 一个 服务
- …由 用户* 访问 *
- … 但仅访问“服务器拥有的” YouTube播放列表数据。 我不想访问用户的YouTube数据,我只想修改我自己的播放列表(即,我/服务器所保留的用户名)。
但是我仍然需要帮助。这是我目前的状态:
-
经过几次搜索后,我得知我想做的事情称为“脱机访问”(重点是我的用例,几乎就是我的用例):
“在某些情况下,当用户不存在时,您的应用程序可能需要访问Google API。这样的示例包括备份服务和应用程序, 这些 服务和应用程序
恰好在星期一早上8点发布博客文章, 这种访问方式称为“离线”,Web服务器应用程序可能会请求用户进行离线访问,而正常的默认访问方式称为“在线”。 ”
…
→因此,我应该继续做我现在正在做的事情,继续请求访问我的YouTube帐户,但是要使用该type_access=offline
标志来获取令牌,并继续/将其用于后续请求。 -
“ 脱机访问” 和“ 使用刷新令牌” 部分是完全有意义的,但仍处于常规HTTP级别。还是一个新手,我看不到如何将这些原理集成到我的Python代码中,也没有在附近找到任何示例Python代码…。
→谁能帮我举一个Python示例来说明如何以及在哪里使用这个标志? -
…尤其是在学习之后
oauth2client.appengine.OAuth2Decorator.oauth_required
,我仍然不确定是否可以根据自己的情况来做,还是应该自己做。
→您怎么看?
谢谢你的时间; 如果需要,我还会在irc://irc.freenode.net/#appengine上进行环聊ronj
。
问题答案:
检索令牌时,默认为脱机访问;您可能在出现的OAuth对话框中注意到了这一点:
不使用应用程序时执行这些操作
当您的用户以装饰有decorator.oauth_required
该用户凭据的方法接受OAuth对话框时,该信息将存储在数据存储区中, 包括
刷新令牌。
一旦拥有以下凭据对象之一,就可以使用它,因此可以授权HTTP对象调用APIS:
import httplib2
http = credentials.authorize(httplib2.Http())
一旦获得授权,它将为您完成所有工作。因此,如果access_token
过期,则第一个API响应将为401
,因此该credentials
对象将使用refresh_token
来获取新access_token
的请求并再次发出请求。
如果您知道用户ID,则可以credentials
按照如何在GAE任务队列中进行需要OAuth的操作中所述从数据存储中检索。:
from oauth2client.appengine import CredentialsModel
from oauth2client.appengine import StorageByKeyName
credentials = StorageByKeyName(
CredentialsModel, user_id, 'credentials').get()
注意/注意事项:
如果用户已经授权了您的客户端ID,则随后您为这些用户执行OAuth时,他们将不会看到OAuth对话框,并且不会为您提供刷新令牌。 仅
当刷新令牌通过OAuth对话框时才能提供刷新令牌,但是由于用户已经授权了您的客户端ID,因此规范假定您已经有了刷新令牌。
这通常在开发人员测试OAuth时出现,因为他们将使用一个测试帐户多次通过该流程,并且在接受第二,第三,第四,…次之后,他们再也看不到刷新令牌。解决此问题的一种简单方法是approval_prompt=force
用作OAuth2Decorator
构造函数的参数。每次您为用户执行OAuth时,都会强制显示OAuth对话框。
但是,这 不会 导致每次为给定用户提供请求时都显示对话框。这将是一个 糟糕的
用户体验。取而代之的是,SACSID
可以使用请求库中的cookie(客户端库和某些App
Engine库)来确定当前用户是谁。一旦库知道了当前用户,它就可以从数据存储中为该用户获取您现有的 存储 令牌/
credentials
,而无需任何麻烦对话框。