Не удалось получить доступ к BigQuery с локального сервера разработки App Engine

В недавнем выпуске SDK Google App Engine была добавлена ​​поддержка метода AppAssertionCredentials на сервере разработки. Чтобы использовать этот метод локально, добавьте следующие аргументы в 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) 

Чтобы использовать их:

1. В Google Developer Console выберите проект, затем перейдите к «API & auth» -> «Учетные данные» -> «Создать новый идентификатор клиента».

2. Выберите «Учетная запись службы» и следуйте инструкциям для загрузки закрытого ключа в формате PKCS12 (.p12). Обратите внимание на адрес электронной почты для учетной записи службы.

3. Убедитесь, что вы добавили этот адрес электронной почты учетной записи службы на вкладку «Разрешения» для любого проекта, который содержит данные, к которым он должен получить доступ, по умолчанию он добавляется в команду проекта, в которой он был создан.

4. Преобразуйте формат PKCS12 в формат PKCS1, используя следующую команду:

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

5. Запустите dev_appserver.py как:

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

6. Используйте модуль appidentity и AppAssertionCredentials таким же образом, как обычно, на производстве.

Убедитесь, что /path/to/secret.pem находится вне исходного каталога вашего приложения, чтобы он не был случайно развернут как часть вашего приложения.

Таким образом, поиск глубже для PyCrypto и локальной песочницы appengine приводит меня к этой теме и ответу специально …

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

Это зафиксировано в 1.7.4. Однако для установки PyCrypto вы должны использовать easy_install -Z (- always-unzip). Параметр zipfile по умолчанию в OSX 10.8 несовместим с эмуляцией песочницы в dev_appserver.

Решение оказалось очень простым …

Я использовал:

 sudo easy_install pycrypto 

и это должно было быть:

 sudo easy_install -Z pycrypto 

как указано выше. Использование PIP также будет работать:

 pip install pycrypto 

или ручная загрузка и установка pycrypto также будут работать. Я тестировал все три.

Если вы установили pycrypto с easy_install и без флага -Z, тогда вам может понадобиться установить pip, чтобы вы могли легко удалить pycrypto …

 easy_install pip 

для записи я построил и установил libgmp, так как pil и ручная установка показали это предупреждение …

предупреждение: библиотека GMP или MPIR не найдена; Не строится Crypto.PublicKey._fastmath.

Хотя это дало мне быстрый ход, не было существенным решение проблемы, поскольку Crypto libs изящно не замедляется.

Еще один момент, который немного подтолкнул меня, – я удалил pycrypto из app.yaml во время тестирования, чтобы узнать, может ли OpenSSL дать мне все, что мне нужно.

Поэтому не забудьте добавить …

 - name: pycrypto version: latest 

в app.yaml в разделе « libraries: раздел».

При этом отсутствует встроенная библиотека _counter не была импортирована, поэтому счетчик не прошел и т. Д.

Также для записи любой разговор о необходимости переместить Crypto в сами папки приложений или из местоположения Mac OS X по умолчанию /Library/Python/2.7/site-packages/Crypto был действителен только в более ранних версиях dev-сервера.

Аналогично, теперь нет необходимости редактировать какие-либо списки _WHITE_LIST_C_MODULES (который находится в sandbox.py в appengine 1.8 onwards, который также включает в себя регулярное выражение, которое позволяет Crypto.Util._counter и т. Д.),

Другой бит головоломки на случай, если вы доберетесь до того, как обнаружите ключевую проблему, заключается в том, что ключевой файл, который вы загружаете с консоли, является PKCS12 и загружается в виде шестнадцатеричного текста, поэтому я преобразовал его в двоичный код, а затем преобразовал его в PEM, чтобы я может включать его в исходный код.

Я боролся с этим один день или два. И наконец я смог заставить localhost работать с аутентификацией сервера на сервер, учетной записью службы и сертификатом .p12.

Если это вообще полезно кому-либо, вот простой смысл: https://gist.github.com/dandelauro/7836962

Я согласен с первым сообщением – локальное / производственное сопротивление – настоящая боль в а **. AppAssertionCredentials – это правильный способ продолжить производство, и я не хочу иметь два разных пути кода между производством и localhost. Поэтому среда разработки должна быть настроена так, чтобы она могла выполнять требуемую аутентификацию, не затрагивая основной путь к коду.

Например, возможно, разработчик мог войти в свою учетную запись Google с помощью appcfg.py, а затем этот auth будет кэшироваться на такой период, что AppAssertionCredentials будет работать. Учетной записи разработчика Google могут быть предоставлены разрешения для соответствующих сред (например, dev и test для нас)

re: «local BigQuery» – у нас есть некоторые исходные материалы, которые используют SQLLite для имитации взаимодействия BigQuery для модульных тестов и других автономных / локальных тестов, но, конечно, это не отличная симуляция. Я согласен с тем, что все продукты Cloud Platform должны тратить столько времени на размышления о времени разработки, как в App Engine.

Возможно ли получить локальный сервер разработки App Engine для аутентификации с помощью удаленного сервиса BigQuery?

Я думаю, что невозможно использовать AppAssertionCredentials качестве метода проверки подлинности между службой BigQuery и локальным сервером App Engine.

В качестве альтернативы, я использую аутентификацию OAuth2, которая связана с конкретным пользователем (этот пользователь должен быть зарегистрирован в вашем проекте на консоли google api ) для доступа к BigQuery с локального сервера App Engine.

Для получения аутентификации пользователя OAuth2 я использую модуль oauth2client.client в коде приложения.

Надеюсь, это будет полезно для вашей проблемы.

Обновлено:

Это то, что я делаю для получения авторизации пользователя OAuth2.

Отредактировано:

Добавлен отсутствующий оператор импорта. Спасибо, маты!

 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)