Djangae Gauth интеграция

Question

Я следую части «Gauth-аутентификации» документации Djangae, но сталкиваюсь с неожиданным поведением.

Я настроил urls.py и settings.py, как указано в документации (текущие настройки в основном являются результатом использования скаффолда Djangae), но ни в коем случае пользователи не должны проходить аутентификацию, используя или связывая свою учетную запись Google.Я попытался un / setting DJANGAE_CREATE_UNKNOWN_USER, но это никак не отразилось.

Я также попытался запустить команды, вдохновленные sitepackages / prod / djangae / contrib / gauth / tests.py, в моей локальной оболочке, чтобычтобы убедиться, что внутренняя конфигурация правильно настроена и что пользователи действительно могут проходить аутентификацию с помощью AppEngineUserAPIBackend, но это не удается, поскольку в моей пользовательской модели (djangae.contrib.gauth_datastore.models.GaeDatastoreUser), по-видимому, отсутствуют обязательные атрибуты: AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.

Итак, я неправильно понимаю, как все это должно работать, и должен предпринять некоторые дополнительные шаги, чтобы войти в систему Google Sign-In?Или я (вероятно) неправильно настроил свое приложение?(Я рад включить обобщенные версии моей конфигурации, но, как я уже сказал, они пришли непосредственно из Djangae Scaffold или из документации.)

ОБНОВЛЕНИЕ: Интересно, если я уберу флаг --headless измоя конфигурация Behavior suite, я вижу ожидаемое поведение.Браузер (Chrome) перенаправляется на https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F

Среда:

Djangae (0.9.11)

Django (1.11.19)

Answer 1

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

Из документа App Engine «Обзор Python API пользователя»:

Учетные записи Google и сервер разработки

Сервер разработки имитирует систему учетных записей Google с использованием фиктивного экрана входа.Когда ваше приложение вызывает API пользователей для получения URL-адреса для экрана входа, API возвращает URL-адрес специального сервера разработки, который запрашивает адрес электронной почты, но не вводит пароль.В это приглашение можно ввести любой адрес электронной почты, и приложение будет вести себя так, как будто вы вошли в систему с учетной записью с этим адресом.

Экран входа в систему также содержит флажок, указывающий, является ли учетная запись фиктивнойявляется администратором;то есть, имеет ли учетная запись примитивную роль «Просмотр», «Редактор» или «Владелец», или предопределенную роль администратора приложений App Engine.Если вы установите этот флажок, приложение будет вести себя так, как будто вы вошли в систему с использованием учетной записи администратора.

Аналогично, API-интерфейс пользователя возвращает URL-адрес выхода, который отменяет фиктивный вход.

Уникальный идентификатор объекта User на сервере разработки рассчитывается на основе адреса электронной почты.Два уникальных адреса электронной почты всегда представляют двух уникальных пользователей на сервере разработки.

Лично я считаю, что этот дизайн очень несовершенен.Я не знаю, что Google думает о манифесте «Двенадцать факторов», но такое поведение является вопиющим нарушением статьи 10 (Dev / Prod Parity), которая кратко излагается как «Делайте разработку, постановку и производство как можно более схожими».Я не вижу причин, по которым полный поток авторизации / перенаправления не будет работать в локальной песочнице, и, по крайней мере, пользователи должны иметь возможность выбрать его.(Я хотел бы любить , чтобы выяснить, что это вариант.)

Самая важная часть об этом условном поведении заключается в том, что API объекта пользователя отличается, поэтому я виделошибка, упомянутая в моем вопросе (объект 'GaeDatastoreUser' не имеет атрибута 'user_id').У локального пользователя также нет метода nickname.