Приложение Python GAE, использующее двухсторонний OAuth и трехсторонний OAuth одновременно

Я кодирую приложение Python - Google App Engine. Это приложение должно делать две важные вещи:

  • Напишите в календаре пользователя.
  • Напишите в профиле пользователя (работа с пользователями в домене Google Apps)

Первая операция легкая. Если я понял OAuth, это классический трехсторонний сценарий. Сценарий, для которого изначально разрабатывался OAuth. Зарегистрированный пользователь предоставляет учетные данные клиенту (моему приложению) для доступа к данным пользователя (календарю) от его/ее имени. Таким образом, это можно сделать только с учетными данными зарегистрированного пользователя.

Вторая операция не так проста. Это невозможно сделать только с учетными данными зарегистрированного пользователя. Это двухсторонний сценарий OAuth. Итак, мне нужно делегировать учетную запись администратора домена Google Apps для доступа к профилям пользователей с помощью API профилей Google (через библиотеку данных Google). До сих пор я жестко вводил пользователя/пароль администратора в файл json, и мое приложение загружало этот файл. Но для меня это звучит грязно.

В конце концов, мое приложение должно обрабатывать классический трехэтапный сценарий OAuth (нет проблем, просто нужны учетные данные зарегистрированного пользователя) плюс двухэтапный сценарий OAuth (требуются учетные данные администратора).

Есть ли какой-либо официальный или более элегантный способ обработки обоих сценариев в Google App Engine, работающий с доменом Google Apps, с жесткими учетными данными администратора?

Спасибо заранее


python-2.7 oauth-2.0 google-app-engine google-apps 2-legged
person Jorge Arévalo    schedule 27.12.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Насколько мне известно, нет способа авторизовать операцию записи в Google Contacts Data API с использованием двухстороннего OAuth.

В документации Google указано, какие API доступны через двусторонний OAuth, но кажется, что кто-то в Google забыл указать, что некоторые из них доступны только для чтения :-S

У некоторых людей была такая же проблема здесь и здесь.

Я с нетерпением жду, когда кто-нибудь из Google исправит это. До тех пор единственным известным мне вариантом является жесткое кодирование учетных данных уровня администратора. Мне это совсем не нравится: это грязно, но эффективно. Если кто-то знает более элегантный способ на уровне дзен, пожалуйста, просветите нас!

person methadata    schedule 27.12.2012
comment
Об этом было объявлено в апреле 2012, что OAuth 1.0 (или двусторонний OAuth, как вы его называли) устарел, так как использует традиционный пароль (вход клиента), поэтому в ваших интересах заставить это работать с OAuth 2.0. Я постараюсь найти полезное решение по этому вопросу. - person bossylobster; 28.12.2012
comment
Спасибо за вашу помощь. Пока что наша большая проблема заключается в том, что нам нужны учетные данные администратора. Таким образом, учетные данные OAuth 2.0, которые мы получаем, например, через oauth2decorator_from_clientsecrets, недействительны. Я прав? (client_secrets.json загружается из консоли Google API. Это идентификатор клиента для веб-приложений) - person Jorge Arévalo; 03.01.2013