google app engine - tutorial - No se puede acceder a BigQuery desde el servidor de desarrollo local de App Engine

google cloud bigquery

Question

Esta es específicamente una pregunta relacionada con la autorización de servidor a servidor entre una aplicación de Python AppEngine de Google y BigQuery de Google, pero podría ser relevante para otros servicios en la nube.

tldr; ¿Es posible conseguir que el servidor de desarrollo local de App Engine se autentique con el servicio remoto de BigQuery? Mejor aún, ¿hay un BigQuery local?

Entiendo que AppAssertionCredentials actualmente no funciona en el servidor de desarrollo local, aunque eso en sí mismo es muy frustrante.

El método alternativo que funciona para el código python estándar, fuera del entorno limitado del servidor de desarrollo local, detallado here no funciona para el servidor de desarrollo local porque incluso con PyCrypto habilitado el entorno limitado no permite algunos módulos posix, por ejemplo, ''pwd''.

Tengo AppAssertionCredentials trabajando en el servidor remoto y el método SignedJwtAssertionCredentials trabajando localmente en python nativo, por lo que las cuentas de servicio están configuradas correctamente.

Las importaciones fallan dentro de oauth2client / crypt.py dentro de los bloques try / except - después de comentarlas, las excepciones de la lista blanca de sandbox se ven fácilmente.

He jugueteado con agregar ''pwd'' a la lista blanca, luego aparece otro problema, así que salí corriendo de ese agujero de conejo.

Intenté incluir PyCrypto directamente en el proyecto con resultados similares.

También lo intenté con OpenSSL con resultados similares.

He buscado un PyCrypto específico para appengine local en vano, ¿me he perdido uno? Debo decir que esto está en Mac OSX. ¿Tal vez debería encender un linux box y probarlo?

Answer 1

¿Es posible conseguir que el servidor de desarrollo local de App Engine se autentique con el servicio remoto de BigQuery?

Creo que es imposible utilizar AppAssertionCredentials como método de autenticación entre el servicio BigQuery y su servidor local de App Engine actualmente.

Alternativamente, estoy usando la autenticación OAuth2 que está asociada con un usuario específico (este usuario debe estar registrado en su proyecto en la consola de google api ) para acceder a BigQuery desde el servidor local de App Engine.

Para obtener la autenticación de usuario OAuth2, uso el módulo oauth2client.client en el código de la aplicación.

Espero que esto sea útil para tu problema.

Actualizado:

Esto es lo que estoy haciendo para obtener la autorización de usuario OAuth2.

Editado:

Se ha agregado un estado de importación faltante. Gracias mates!

import os
import webapp2
import httplib2
from oauth2client.client import OAuth2Credentials
from oauth2client.appengine import StorageByKeyName, CredentialsModel, OAuth2DecoratorFromClientSecrets
from google.appengine.api import users

oauth2_decorator = OAuth2DecoratorFromClientSecrets(
    os.path.join(os.path.dirname(__file__), ''client_secrets.json''),
    scope=''https://www.googleapis.com/auth/bigquery'')
oauth2_decorator._kwargs = {''approval_prompt'': ''force''}


class TestPage(webapp2.RequestHandler):
  @oauth2_decorator.oauth_required
  def get(self):
    user_id = users.get_current_user().user_id()
    credentials = StorageByKeyName(CredentialsModel, user_id, ''credentials'').locked_get()
    http = credentials.authorize(httplib2.Http()) # now you can use this http object to access BigQuery service


application = webapp2.WSGIApplication([
  (''/'', TestPage),
  (oauth2_decorator.callback_path, oauth2_decorator.callback_handler()),
], debug=True)

Answer 2

Así que buscando más profundamente para PyCrypto y sandbox appengine local, me llevan a este hilo y respuesta específicamente ...

https://code.google.com/p/googleappengine/issues/detail?id=1627#c22

Esto está arreglado en 1.7.4. Sin embargo, debe usar easy_install -Z (--always-unzip) para instalar PyCrypto. La opción de archivo zip predeterminada en OSX 10.8 es incompatible con la emulación de sandbox en dev_appserver.

La solución resulta ser muy directa ...

Solía:

sudo easy_install pycrypto

y debería haber sido:

sudo easy_install -Z pycrypto

según el hilo de arriba. El uso de PIP también funcionará:

pip install pycrypto 

o una descarga manual e instalación de pycrypto también funcionará. Probé los tres.

Si ha instalado pycrypto con easy_install y sin -Z flag, entonces puede instalar pip para que pueda desinstalar fácilmente pycrypto ...

easy_install pip

para el registro que construí e instalé libgmp, ya que Pil y la instalación manual mostraron esta advertencia ...

advertencia: biblioteca GMP o MPIR no encontrada; No construyendo Crypto.PublicKey._fastmath.

Aunque esto me brindó rapidez, no fue esencial resolver el problema ya que las Crypto libs no logran ralentizar.

Otro punto que me hizo tropezar un poco fue eliminar pycrypto de app.yaml mientras probaba para ver si OpenSSL podría darme todo lo que necesito.

Así que no te olvides de agregar ...

- name: pycrypto
  version: latest

en app.yaml en las libraries: sección.

Con esto falta la biblioteca nativa _counter no se importó, por lo tanto el contador falló, etc.

También para el registro, cualquier conversación sobre tener que mover Crypto a las carpetas de aplicaciones ellos mismos o fuera de la ubicación predeterminada de Mac OS X de /Library/Python/2.7/site-packages/Crypto solo era válida en las versiones anteriores del servidor de desarrollo.

Del mismo modo, ahora no hay necesidad de editar ninguna lista _WHITE_LIST_C_MODULES (que está en sandbox.py en appengine 1.8 en adelante, que también incluye la expresión regular que permite Crypto.Util._counter, etc.)

La otra parte del acertijo en caso de que llegue aquí antes de descubrir el problema clave es que el archivo clave que descarga de la consola es PKCS12 y se descarga como texto hexadecimal, por lo que lo convertí en binario y luego lo convertí en un PEM, así que podría incluirlo en el código fuente.

Answer 3

Estoy de acuerdo con la primera publicación: la impedancia de producción / host local es un verdadero dolor en a **. AppAssertionCredentials es la forma correcta de continuar la producción y no quiero tener dos rutas de código diferentes entre producción y localhost. Por lo tanto, los entornos de desarrollo deben ajustarse para poder realizar la autenticación requerida sin afectar la ruta del código principal.

Por ejemplo, tal vez un desarrollador podría iniciar sesión con su propia cuenta de Google usando appcfg.py y luego esa autenticación se almacenaría en caché durante un período tal que funcionaría AppAssertionCredentials. La cuenta de Google del desarrollador podría tener permisos en los entornos apropiados (desarrollo y prueba para nosotros, por ejemplo)

re: "BigQuery local": tenemos algunos elementos iniciales que utilizan SQLLite para simular interacciones de BigQuery para pruebas unitarias y otras pruebas fuera de línea / locales, pero, por supuesto, no es una gran simulación. Acepto que todos los productos de Cloud Platform necesitan dedicar tanto tiempo a pensar en la experiencia de tiempo de desarrollo que tiene App Engine.

Answer 4

Luché con este por uno o dos días. Y finalmente pude hacer que localhost trabajara con autenticación de servidor a servidor, una cuenta de servicio y un certificado .p12.

Si es útil para todos, aquí hay una idea básica: https://gist.github.com/dandelauro/7836962

Answer 5

Un lanzamiento reciente de Google App Engine SDK agregó soporte para el método AppAssertionCredentials en el servidor de desarrollo. Para usar este método localmente, agregue los siguientes argumentos a dev_appserver.py :

$ dev_appserver.py --help
...
Application Identity:
  --appidentity_email_address APPIDENTITY_EMAIL_ADDRESS
                        email address associated with a service account that
                        has a downloadable key. May be None for no local
                        application identity. (default: None)
  --appidentity_private_key_path APPIDENTITY_PRIVATE_KEY_PATH
                        path to private key file associated with service
                        account (.pem format). Must be set if
                        appidentity_email_address is set. (default: None)

Para usar estos:

1. En Google Developer Console , seleccione un proyecto y vaya a "API y autenticación" -> "Credenciales" -> "Crear ID de cliente nuevo".

2. Seleccione "Cuenta de servicio" y siga las instrucciones para descargar la clave privada en formato PKCS12 (.p12). Tome nota de la dirección de correo electrónico de la cuenta de servicio.

3. Asegúrese de agregar esa dirección de correo electrónico de la cuenta de servicio a la pestaña "Permisos" para cualquier proyecto que contenga datos a los que necesite acceder, de manera predeterminada se agrega al equipo del proyecto en el que se creó.

4. Convierta el formato PKCS12 al formato PKCS1 con el siguiente comando:

   $ cat /path/to/xxxx-privatekey.p12 | openssl pkcs12 -nodes -nocerts -passin pass:notasecret | openssl rsa > /path/to/secret.pem

5. Inicie dev_appserver.py como:

   $ dev_appserver.py --appidentity_email_address [email protected] --appidentity_private_key_path /path/to/secret.pem ...

6. Use el módulo de aplicación y AppAssertionCredentials de la misma manera localmente que lo haría normalmente en producción.

Asegúrese de que /path/to/secret.pem esté fuera del directorio de origen de la aplicación para que no se despliegue accidentalmente como parte de su aplicación.