python - 如何在 GAE/Python 上进行 'access_type=offline'/server-only OAuth2 操作？

Question

这篇文章是 How to do OAuth-requiring operations in a GAE cron job? 的后续文章，我意识到我误用了 OAuth2DecoratorFromClientSecrets 中的 @oauth_required 装饰器。

如 OAuth 2.0 explained 所述介绍，Oauth 2.0 解决了以下问题:

• 构建服务...
• ...被用户访问...
• ... 并从第三方访问用户数据。

这就是 @oauth_required 的抽象，它做得很好(目前我的应用程序“有效”:如果我触发刷新页面，我被要求授权访问我的 YouTube 数据到我的应用程序，其余的如下)。但这不是我想要的!我的应用程序做了一些更简单的事情，它每天使用我的凭据创建一个 youtube 播放列表，无需任何用户输入。因此，为了与上述 3 层谈判进行比较，我想要:

• 服务
• ...被用户访问
• ... 但只访问“服务器拥有的”YouTube 播放列表数据。我不想访问用户的 YouTube 数据，我只想修改我(即我/服务器保留的用户 ID)拥有的播放列表。

但我仍然需要帮助才能做到这一点；这是我目前的状态:

1. 经过几次搜索，我了解到我想要做的事情叫做 Offline Access (强调我的，这几乎正是我的用例):
   “在某些情况下，您的应用程序可能需要在用户不在场时访问 Google API。这方面的示例包括备份服务和在周一早上 8 点整发布博文的应用程序。这种访问方式称为离线，Web 服务器应用程序可能会请求用户进行离线访问。正常和默认的访问方式称为在线。”...
   → 所以我应该继续做我现在正在做的事情，继续请求访问我的 YouTube 帐户，但是使用 type_access=offline 标志来获取 token ，并坚持/使用它以供后续使用要求。

2. Offline Access 和 Using a Refresh Token 部分完全有意义，但停留在一般的 HTTP 级别。作为一个新手，我不知道如何将这些原则整合到我的 Python 代码中，而且我也没有找到任何示例 Python 代码....
   → 谁能帮我举一个 Python 示例来说明如何以及在何处使用此标志？

3. ...特别是，在学习了 oauth2client.appengine.OAuth2Decorator.oauth_required 之后，我仍然不确定我是否可以根据我的情况使用它，或者我是否应该这样做我自己的东西。
   → 你怎么看？

感谢您的宝贵时间；如果需要，我也会以 ronj 的身份在 irc://irc.freenode.net/#appengine 上闲逛。

Answer 1

离线访问是default检索 token 时；您可能已经在出现的 OAuth 对话框中注意到了这一点:

Perform these operations when I'm not using the application

当您的用户在用 decorator.oauth_required 修饰的方法中接受 OAuth 对话框时，该用户的凭据将存储在数据存储中，包括刷新 token 。

一旦您拥有这些凭据对象之一，就可以使用它来授权 HTTP 对象调用 APIS:

import httplib2
http = credentials.authorize(httplib2.Http())

一旦授权，它将为您完成所有工作。因此，如果 access_token 过期，第一个 API 响应将是 401，因此 credentials 对象将使用 refresh_token 获取新的access_token 并再次发起请求。

如果您知道用户 ID，则可以按照 How to do OAuth-requiring operations in a GAE Task Queue? 中的说明从数据存储中检索凭据 :

from oauth2client.appengine import CredentialsModel
from oauth2client.appengine import StorageByKeyName
credentials = StorageByKeyName(
     CredentialsModel, user_id, 'credentials').get()

注意/陷阱:

如果用户已经授权了您的客户端 ID，则您以后为这些用户执行 OAuth 时，他们将看不到 OAuth 对话框，您也不会获得刷新 token 。如果他们通过 OAuth 对话框，则可以仅提供刷新 token ，但由于用户已经授权了您的客户端 ID，因此规范假定您已经拥有刷新 token 。

这通常在开发人员测试 OAuth 时出现，因为他们会使用测试帐户多次执行流程，并且在接受第 2、3、4 次……之后，他们再也看不到刷新 token 。一个简单的解决方法是使用 approval_prompt=force 作为 OAuth2Decorator 构造函数的参数。这将在您每次为用户执行 OAuth 时强制显示 OAuth 对话框。

但是，这不会导致每次为给定用户提供请求时显示对话框；这将是一种糟糕的用户体验。相反，请求中的 SACSID cookie 可以(由客户端库和一些 App Engine 库)用于确定当前用户是谁。一旦库知道当前用户，它就可以从数据存储中为该用户获取您现有的存储 token /凭据，并且不需要刺耳的对话。