Подтвердить что ты не робот

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

Это конкретный вопрос, связанный с авторизацией сервера и сервера между приложением Google AppEngine на Python и Google BigQuery, но может иметь значение для других облачных сервисов.

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

Я понимаю, что AppAssertionCredentials в настоящее время не работает на локальном сервере разработки, хотя это само по себе очень расстраивает.

Альтернативный метод, который работает для стандартного кода python, вне локальной изолированной программной среды сервера разработки, подробный здесь не работает для локального сервера разработки, потому что даже с включенным PyCrypto песочница не позволяет использовать некоторые posix-модули, например 'PWD'.

У меня есть AppAssertionCredentials, работающий на удаленном сервере, и метод SignedJwtAssertionCredentials, работающий на локальном питоне локально, поэтому учетные записи службы настроены правильно.

Импорт завершился неудачно в пределах oauth2client/crypt.py в блоках try/except - после комментирования их исключение исключений из "песочницы" можно легко увидеть.

Я возился с добавлением "pwd" в белый список, затем возникла другая проблема, поэтому я выбежал из этой кроличьей дыры.

Я попытался включить PyCrypto непосредственно в проект с похожими результатами.

Я также пытался использовать OpenSSL с аналогичными результатами.

Я искал локальный appengine, специфический PyCrypto, безрезультатно, пропустил ли я один? Я должен сказать, что это на Mac OSX - возможно, я должен запустить linux box и дать этому идти?

4b9b3361

ОТВЕТЫ

Ответ 1

В недавнем выпуске 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)

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

  • В консоли разработчика Google выберите проект, затем перейдите к "API и auth" → "Учетные данные" → "Создать новый идентификатор клиента".

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

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

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

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

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

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

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

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

Ответ 2

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

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

Это зафиксировано в 1.7.4. Однако вы должны использовать easy_install -Z (- всегда-распаковать) для установки PyCrypto. Параметр 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, поэтому я мог бы включить его в исходный код.

Ответ 3

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

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

Ответ 4

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

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

В качестве альтернативы, я использую аутентификацию OAuth2, которая связана с конкретным пользователем (этот пользователь должен быть зарегистрирован в вашем проекте в google api console) для доступа к 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)

Ответ 5

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

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

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