serviceaccountcredentials - ¿Cómo hacer ''access_type=offline''/server-only OAuth2 operaciones en GAE/Python?

python google engine

Question

Esta publicación es una continuación de ¿Cómo hacer las operaciones que requieren OAuth en un trabajo cron de GAE? , donde me di cuenta de que estoy utilizando mal el @oauth_required decorator de OAuth2DecoratorFromClientSecrets .

Tal como se describe en la presentación explicada de OAuth 2.0 , Oauth 2.0 resuelve el problema de:

• Construyendo un servicio ...
• ... accedido por un usuario ...
• ... y acceder a los datos del usuario de un tercero .

Eso es lo que hace @oauth_required resúmenes, y lo hace bien (actualmente mi aplicación "funciona": si activa la página de actualización, me piden que autorice el acceso a mis datos de youtube a mi aplicación, y el resto sigue). ¡Pero eso no es lo que quiero! Mi aplicación hace algo más simple, que es crear una lista de reproducción de youtube todos los días con mis credenciales y sin ninguna intervención del usuario . Entonces, para comparar con la negociación anterior de 3 niveles, quiero:

• Un servicio
• ... accedido por los usuarios
• ... pero solo accediendo a los datos de la lista de reproducción de YouTube propiedad del servidor. No quiero ningún acceso a los datos de YouTube del usuario, solo quiero modificar una lista de reproducción que yo (es decir, me / a userid persistió por el servidor).

Pero todavía necesito ayuda para hacer eso; aquí está mi estado actual:

1. Después de algunas búsquedas, descubrí que lo que quiero hacer se llama Acceso sin conexión (énfasis mío, que es casi exactamente mi caso de uso):
   "En algunos casos, es posible que su aplicación necesite acceder a una API de Google cuando el usuario no está presente. Algunos ejemplos de esto incluyen servicios de copia de seguridad y aplicaciones que hacen publicaciones en blogger exactamente a las 8 a.m. del lunes por la mañana . las aplicaciones de servidor pueden solicitar acceso sin conexión a un usuario. El estilo de acceso normal y predeterminado se llama en línea ". ...
   → Así que debería seguir haciendo lo que estoy haciendo en este momento, seguir solicitando acceso a mi cuenta de YouTube, pero hacerlo usando el type_access=offline para obtener un token, y persistir / usarlo para solicitudes posteriores.

2. Las secciones Acceso sin conexión y Uso de token de actualización tienen total sentido, pero se mantienen en un nivel HTTP general. Siendo todavía un novato, no veo cómo integrar esos principios en mi código Python, y no encontré ningún código de Python de muestra ...
   → ¿Alguien podría ayudarme con un ejemplo de Python que ilustra cómo y dónde usar esta bandera?

3. ... y, en particular, después de estudiar oauth2client.appengine.OAuth2Decorator.oauth_required , todavía no estoy seguro si puedo doblarlo en mi caso, o si debo hacer lo mío.
   → ¿Qué piensas?

Gracias por tu tiempo; si es necesario, también estoy saliendo con irc: //irc.freenode.net/#appengine como ronj .

Answer 1

El acceso fuera de línea es el predeterminado al recuperar tokens; es posible que haya notado esto en el diálogo de OAuth que aparece:

Realice estas operaciones cuando no estoy usando la aplicación

Cuando su usuario acepta el cuadro de diálogo OAuth en un método decorado con decorator.oauth_required las credenciales para ese usuario se almacenarán en el almacén de datos, incluido el token de actualización.

Una vez que tenga uno de estos objetos de credenciales, puede usarlo para autorizar un objeto HTTP para llamar a APIS:

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

y una vez autorizado, hará todo el trabajo por usted. Por lo tanto, si access_token ha caducado, la primera respuesta de API será 401 y, por lo tanto, el objeto de credentials utilizará refresh_token para obtener un nuevo access_token y realizar nuevamente la solicitud.

Si conoce la ID de usuario, puede recuperar las credentials del almacén de datos como se describe en ¿Cómo hacer las operaciones que requieren OAuth en una cola de tareas de GAE? :

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

Nota / Gotcha:

Si un usuario ya ha autorizado su ID de cliente, las siguientes veces que ejecute OAuth para estos usuarios no verán el cuadro de diálogo de OAuth y no recibirá un token de actualización. Solo se puede dar un token de actualización si pasan por el cuadro de diálogo OAuth, pero como el usuario ya ha autorizado su ID de cliente, la especificación asume que ya tendrá un token de actualización.

A menudo, esto ocurre cuando los desarrolladores prueban OAuth, ya que pasarán por el flujo varias veces con una cuenta de prueba y después de aceptar la 2ª, 3ª, 4ª, ... veces, nunca ven el token de actualización. Una forma sencilla de evitar esto es usar approval_prompt=force como argumento para el constructor OAuth2Decorator . Esto obligará a que aparezca el cuadro de diálogo OAuth cada vez que realice OAuth para un usuario.

Sin embargo, esto no hará que aparezca el cuadro de diálogo cada vez que se atiende una solicitud para un usuario determinado; esta sería una experiencia de usuario TERRIBLE En cambio, la cookie SACSID de la solicitud puede ser utilizada (por la biblioteca del cliente y algunas bibliotecas de App Engine) para determinar quién es el usuario actual. Una vez que la biblioteca conoce al usuario actual, puede obtener sus tokens / credentials almacenadas para ese usuario desde el almacén de datos y no se necesitará un diálogo discordante.