Эта страница переведена с помощью Cloud Translation API.

Миграция со службы пользователей App Engine на платформу Cloud Identity (модуль 21).

1. Обзор

Серия курсов по кодированию Serverless Migration Station (практические руководства для самостоятельного обучения) и сопутствующие видеоролики призваны помочь бессерверным разработчикам Google Cloud модернизировать свои приложения, помогая им выполнить одну или несколько миграций, в первую очередь отходя от устаревших сервисов. Это сделает ваши приложения более портативными и предоставит вам больше возможностей и гибкости, позволяя интегрироваться с более широким спектром облачных продуктов и получать к ним доступ, а также упростить обновление до более новых языковых версий. Первоначально эта серия ориентирована на самых первых пользователей облака, в первую очередь на разработчиков App Engine (стандартной среды), но эта серия достаточно широка, чтобы включать в себя другие бессерверные платформы, такие как Cloud Functions и Cloud Run , или другие бессерверные платформы, если это применимо.

Цель этой лаборатории кода — показать разработчикам App Engine Python 2, как перейти с API/службы App Engine Users на Cloud Identity Platform (GCIP). Также существует неявная миграция с App Engine NDB на Cloud NDB для доступа к хранилищу данных (в основном описанная в модуле миграции 2), а также обновление до Python 3.

В модуле 20 рассказывается, как добавить использование Users API в пример приложения модуля 1. В этом модуле вы возьмете готовое приложение Модуля 20 и перенесете его использование на Cloud Identity Platform.

Вы узнаете, как

Замените использование службы App Engine Users на Cloud Identity Platform.
Замените использование App Engine NDB на Cloud NDB (см. также Модуль 2).
Настройка различных поставщиков удостоверений аутентификации с помощью Firebase Auth
Используйте API Cloud Resource Manager для получения информации IAM проекта.
Используйте Firebase Admin SDK для получения информации о пользователе.
Перенесите пример приложения на Python 3.

Что вам понадобится

Проект Google Cloud Platform с активным платежным аккаунтом GCP.
Базовые навыки Python
Знание основных команд Linux.
Базовые знания разработки и развертывания приложений App Engine.
Пример рабочего приложения App Engine Модуля 20.

Опрос

Как вы будете использовать этот урок?

Только прочитай это

Прочитайте его и выполните упражнения.

Как бы вы оценили свой опыт работы с Python?

Новичок

Средний

Опытный

Как бы вы оценили свой опыт использования сервисов Google Cloud?

Новичок

Средний

Опытный

2. Предыстория

Служба пользователей App Engine — это система аутентификации пользователей, используемая приложениями App Engine. Он предоставляет вход в Google в качестве поставщика удостоверений, предоставляет удобные ссылки для входа и выхода из системы для использования в приложениях, а также поддерживает концепцию пользователей-администраторов и функциональность только для администраторов. Чтобы улучшить переносимость приложений, Google Cloud рекомендует перейти от устаревших сервисов App Engine к автономным сервисам Cloud , например, от сервиса Users к Cloud Identity Platform , среди прочих.

Identity Platform основана на Firebase Authentication и добавляет ряд корпоративных функций, включая многофакторную аутентификацию, поддержку единого входа OIDC и SAML, мультитенантность, соглашение об уровне обслуживания 99,95% и многое другое. Эти различия также выделены на странице сравнения продуктов Identity Platform и Firebase Authentication . Оба продукта имеют значительно больше возможностей, чем функциональность, предоставляемая сервисом «Пользователи».

В этой лаборатории кода Модуля 21 показано переключение аутентификации пользователей приложения со службы пользователей на функции Identity Platform, что наиболее точно отражает функциональность, продемонстрированную в Модуле 20. Модуль 21 также включает миграцию из App Engine NDB в Cloud NDB для доступа к хранилищу данных, повторяя миграцию Модуля 2. .

Хотя код Модуля 20 «рекламируется» как пример приложения Python 2, сам исходный код совместим с Python 2 и 3, и он остается таким даже после перехода на Identity Platform (и Cloud NDB) здесь, в Модуле 21. продолжайте использовать службу «Пользователи» при обновлении до Python 3, поскольку переход на Identity Platform не является обязательным. См. лабораторную работу по коду и видео Модуля 17 , чтобы узнать, как продолжать использовать встроенные службы при обновлении до среды выполнения 2-го поколения, например Python 3.

Перенесите приложение на Python 3, а затем, если необходимо, вернитесь на Python 2.

Основная цель разработчиков, модернизирующих свои бессерверные приложения, — перейти на Python 3. Из-за проблем совместимости это руководство переносится с раздела «Пользователи» на Identity Platform и обновляется до Python 3. После перехода на Identity Platform и Python 3 мы рассмотрим резервное копирование. завершенное приложение Модуля 21 для Python 2, которое включает дополнительные шаги. Мы рекомендуем выполнять резервное копирование на Python 2 только тем пользователям, которым по какой-либо причине приходится оставаться на Python 2.

Это руководство включает в себя следующие шаги:

Настройка/Предварительная работа
Обновить конфигурацию
Изменить код приложения

3. Настройка/Предварительная работа

В этом разделе объясняется, как:

Настройте свой облачный проект
Получить базовый образец приложения
(Повторное)развертывание и проверка базового приложения.
Включите новые сервисы/API Google Cloud

Эти шаги гарантируют, что вы начнете с рабочего кода, готового к миграции в автономные облачные службы.

1. Проект установки

Если вы завершили лабораторную работу по Модулю 20, повторно используйте тот же проект (и код). Альтернативно создайте новый проект или повторно используйте другой существующий проект. Убедитесь, что у проекта есть активный платежный аккаунт и включенное приложение App Engine. Найдите идентификатор своего проекта, держите его под рукой во время этой лабораторной работы и используйте его всякий раз, когда вы встретите переменную PROJ_ID .

2. Получите базовый образец приложения.

Одним из предварительных условий является работающее приложение Модуля 20 App Engine, поэтому либо заполните его кодовую лабораторию (рекомендуется; ссылка выше), либо скопируйте код Модуля 20 из репозитория. Независимо от того, используете ли вы свой или наш, мы начнем именно с этого («СТАРТ»). Эта лаборатория кода проведет вас через миграцию, завершающуюся кодом, похожим на тот, что находится в папке репозитория Модуля 21 («FINISH»).

НАЧАЛО: папка модуля 20 (Python 2)
ЗАВЕРШЕНИЕ: папки модуля 21 ( Python 2 или Python 3 )
Весь репозиторий (для клонирования или загрузки ZIP-файла )

Скопируйте папку репозитория модуля 20. Он должен выглядеть так, как показано ниже, и, возможно, у вас может быть папка lib , если вы выполнили лабораторную работу по Модулю 20:

$ ls
README.md               appengine_config.py     templates
app.yaml                main.py                 requirements.txt

3. (Повторное) развертывание и проверка базового приложения.

Выполните следующие шаги, чтобы развернуть приложение Модуля 20:

Удалите папку lib , если она есть, и запустите pip install -t lib -r requirements.txt чтобы заполнить ее заново. Возможно, вам придется использовать pip2 , если у вас установлены Python 2 и 3.
Убедитесь, что вы установили и инициализировали инструмент командной строки gcloud и проверили его использование .
Если вы не хотите вводить свой PROJ_ID при каждой выдаваемой команде gcloud , сначала установите проект Cloud с gcloud config set project PROJ_ID .
Разверните пример приложения с помощью gcloud app deploy
Убедитесь, что приложение работает как положено, без ошибок. Если вы завершили лабораторную работу по Модулю 20, приложение отображает информацию для входа пользователя (адрес электронной почты пользователя, возможный «значок администратора» и кнопку входа/выхода) вверху вместе с последними посещениями (показано ниже).

При входе в систему в качестве обычного пользователя отображается адрес электронной почты пользователя, а кнопка «Вход» меняется на кнопку «Выход»:

При входе в систему с правами администратора адрес электронной почты пользователя отображается вместе с надписью «(admin)» рядом с ним:

4. Включите новые API/сервисы Google Cloud.

Введение

Приложение Модуля 20 использует App Engine NDB и Users API — комплексные службы, которые не требуют дополнительной настройки, в отличие от автономных облачных служб, а обновленное приложение будет использовать как Cloud Identity Platform, так и Cloud Datastore (через клиентскую библиотеку Cloud NDB ). . Кроме того, наша потребность в определении пользователей-администраторов App Engine также требует использования Cloud Resource Manager API .

Расходы

App Engine и Cloud Datastore имеют квоты уровня «Всегда бесплатно» , и пока вы не выходите за рамки этих ограничений, вам не придется платить за выполнение этого руководства. Дополнительную информацию также можно найти на странице цен App Engine и странице цен Cloud Datastore .
Плата за использование Cloud Identity Platform взимается в зависимости от количества активных пользователей в месяц (MAU) или проверок аутентификации; для каждой модели использования доступна некоторая версия «бесплатно». Более подробную информацию можно найти на странице цен . Кроме того, хотя App Engine и Cloud Datastore требуют выставления счетов, использование GCIP само по себе не требует включения выставления счетов, если вы не превышаете его безинструментальные дневные квоты , поэтому рассмотрите это для облачных проектов, которые не включают в себя облако, требующее выставления счетов. API/сервисы.
Использование Cloud Resource Manager API по большей части бесплатное, как указано на странице цен .

Пользователи включают API Cloud из консоли Cloud или из командной строки (с помощью команды gcloud , входящей в состав Cloud SDK ), в зависимости от ваших предпочтений. Начнем с API Cloud Datastore и Cloud Resource Manager.

Из облачной консоли

Перейдите на страницу библиотеки менеджера API (для нужного проекта) в Cloud Console и найдите API с помощью панели поиска.

Включите эти API:

Найдите и нажмите кнопку «Включить» для каждого API отдельно — вам может быть предложено ввести платежную информацию. Например, вот страница API Resource Manager:

Кнопка изменится на «Управление», когда она будет включена (обычно через несколько секунд):

Включите Cloud Datastore таким же образом:

Из командной строки

Хотя включение API из консоли визуально информативно, некоторые предпочитают командную строку. Вы получаете дополнительный бонус в виде возможности одновременного включения любого количества API. Введите эту команду, чтобы включить API Cloud Datastore и Cloud Resource Manager, и дождитесь завершения операции, как показано здесь:

$ gcloud services enable cloudresourcemanager.googleapis.com datastore.googleapis.com
Operation "operations/acat.p2-aaa-bbb-ccc-ddd-eee-ffffff" finished successfully.

Вам может быть предложено ввести платежную информацию.

«URL-адреса» для каждого API, использованного в приведенной выше команде, называются именами служб API, и их можно найти внизу страницы библиотеки для каждого API. Если вы хотите включить другие облачные API для своих приложений, вы можете найти названия соответствующих служб на соответствующих страницах API. Эта команда перечисляет все имена служб для API, которые вы можете включить:

gcloud services list --available --filter="name:googleapis.com" .

Как в облачной консоли, так и в командной строке, после выполнения описанных выше шагов наш образец теперь сможет получить доступ к этим API. Следующие шаги — включить Cloud Identity Platform и внести необходимые изменения в код.

Включение и настройка Cloud Identity Platform (только облачная консоль)

Cloud Identity Platform — это служба Marketplace , поскольку она подключается к ресурсу за пределами Google Cloud или зависит от него, например Firebase Authentication . В настоящее время вы можете включить службы Marketplace только из облачной консоли. Выполните следующие действия:

Перейдите на страницу Cloud Identity Platform в Cloud Marketplace и нажмите кнопку «Включить» . Обновите Firebase Authentication, если будет предложено — это разблокирует дополнительные функции, например, описанные ранее в разделе «Справочная информация» . Вот страница Marketplace, на которой выделена кнопка «Включить» :
После включения платформы идентификации вы можете автоматически попасть на страницу поставщиков удостоверений . Если нет, воспользуйтесь этой удобной ссылкой, чтобы попасть туда.
Включите поставщика Google Auth. Если поставщики не настроены, нажмите «Добавить поставщика» и выберите Google . Когда вы вернетесь на этот экран, запись Google должна быть включена. Google — единственный поставщик аутентификации, который мы используем в этом руководстве для зеркалирования службы пользователей App Engine в качестве упрощенной службы входа в Google. В своих приложениях вы можете включить дополнительных поставщиков аутентификации.
Выбрав и настроив Google и других нужных поставщиков аутентификации, нажмите «Сведения о настройке приложения» и в диалоговом окне обеспечения скопируйте apiKey и authDomain в объект config на вкладке «Интернет», сохранив их оба в безопасном месте. Почему бы не скопировать все это? Фрагмент в этом диалоговом окне жестко запрограммирован и устарел, поэтому просто сохраните наиболее важные фрагменты и используйте их в нашем коде с более одновременным использованием Firebase Auth. После того, как вы скопировали значения и сохранили их в безопасном месте, нажмите кнопку «Закрыть» , завершив все необходимые настройки.

4. Обновить конфигурацию

Обновления конфигурации включают как изменение различных файлов конфигурации, так и создание эквивалента App Engine, но в экосистеме Cloud Identity Platform.

appengine_config.py

При обновлении до Python 3 удалите appengine_config.py
Если вы планируете перейти на Identity Platform, но остаетесь на Python 2, не удаляйте файл. Вместо этого мы обновим его позже во время обратного переноса Python 2.

требования.txt

В файле requirements.txt модуля 20 указан только Flask . Для модуля 21 добавьте следующие пакеты:

Содержимое файла requirements.txt теперь должно выглядеть следующим образом:

flask
google-auth
google-cloud-ndb
google-cloud-resource-manager
firebase-admin

Номера версий пакета

В этом файле requirements.txt для Python 3 нет номеров версий, что означает, что выбраны самые последние версии. Если возникают какие-либо несовместимости, следуйте стандартной практике использования номеров версий для блокировки рабочих версий приложения.

Показательный пример: многие пакеты Python 2 устарели, поэтому номера версий иногда требуются для блокировки пакетов, совместимых с 2.x. В файле requirements.txt Python 2 определенно есть номера версий. Подробнее об этом мы расскажем, когда мы бэкпортируем это приложение на Python 2. Также см. папку «Модуль 21a».

app.yaml

Обновление до Python 3 означает упрощение файла app.yaml . Удалите все, кроме директивы времени выполнения, и установите для нее поддерживаемую в настоящее время версию Python 3. В настоящее время в примере используется версия 3.10.
Если вы остаетесь с Python 2, пока не предпринимайте никаких действий.

ДО:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

Пример приложения Модуля 20 не имеет статических обработчиков файлов. Если ваши приложения это делают, оставьте их нетронутыми. При желании вы можете удалить все обработчики сценариев или просто оставить их для справки, изменив их дескрипторы на auto , как описано в руководстве по миграции app.yaml . Благодаря этим изменениям обновленный app.yaml для Python 3 упрощен до:

ПОСЛЕ:

runtime: python310

Другие обновления конфигурации

Независимо от того, остаетесь ли вы на Python 2 или переходите на Python 3, если у вас есть папка lib , удалите ее.

5. Измените код приложения.

В этом разделе представлены обновления основного файла приложения main.py , заменяющие использование службы App Engine Users на Cloud Identity Platform. После обновления основного приложения вы обновите веб-шаблон templates/index.html .

Обновление импорта и инициализации

Выполните следующие действия для обновления импорта и инициализации ресурсов приложения:

Для импорта замените App Engine NDB на Cloud NDB.
Наряду с Cloud NDB также импортируйте Cloud Resource Manager.
Платформа идентификации основана на Firebase Auth, поэтому импортируйте Firebase Admin SDK.
Облачные API требуют использования API-клиента, поэтому инициируйте его для Cloud NDB сразу после инициализации Flask.

Хотя пакет Cloud Resource Manager импортирован сюда, мы будем использовать его на более позднем этапе инициализации приложения. Ниже приведены импорт и инициализация из Модуля 20, а затем показано, как должны выглядеть разделы после реализации вышеуказанных изменений:

ДО:

from flask import Flask, render_template, request
from google.appengine.api import users
from google.appengine.ext import ndb

app = Flask(__name__)

ПОСЛЕ:

from flask import Flask, render_template, request
from google.auth import default
from google.cloud import ndb, resourcemanager
from firebase_admin import auth, initialize_app

# initialize Flask and Cloud NDB API client
app = Flask(__name__)
ds_client = ndb.Client()

Поддержка пользователей с правами администратора App Engine

В приложение, поддерживающее распознавание пользователей с правами администратора, можно добавить два компонента:

_get_gae_admins() — сопоставляет набор пользователей-администраторов; позвонил один раз и сохранил
is_admin() — проверяет, является ли вошедший в систему пользователь администратором; вызывается при любом входе пользователя

Служебная функция _get_gae_admins() вызывает API Resource Manager для получения текущей политики разрешения Cloud IAM . Политика разрешения определяет и обеспечивает соблюдение того, какие роли каким участникам предоставляются (пользователям-людям, учетным записям служб и т. д.). Установка включает в себя:

Получение идентификатора облачного проекта ( PROJ_ID )
Создание клиента API Resource Manager ( rm_client )
Создание набора ролей администратора App Engine (только для чтения) ( _TARGETS )

Диспетчеру ресурсов требуется идентификатор облачного проекта, поэтому импортируйте google.auth.default() и вызовите эту функцию, чтобы получить идентификатор проекта. Этот вызов содержит параметр, который выглядит как URL-адрес, но имеет область разрешений OAuth2 . При запуске приложений в облаке, например, на виртуальной машине Compute Engine или в приложении App Engine, предоставляется учетная запись службы по умолчанию с широкими привилегиями. В соответствии с рекомендациями по наименьшим привилегиям мы рекомендуем создавать собственные сервисные учетные записи, управляемые пользователями .

Для вызовов API лучше всего еще больше сократить объем ваших приложений до минимального уровня, необходимого для правильной работы. Вызов API Resource Manager, который мы будем выполнять, — это get_iam_policy() , для работы которого требуется одна из следующих областей :

https://www.googleapis.com/auth/cloud-platform
https://www.googleapis.com/auth/cloud-platform.read-only
https://www.googleapis.com/auth/cloudplatformprojects
https://www.googleapis.com/auth/cloudplatformprojects.readonly

Примеру приложения требуется только доступ только для чтения к политике разрешения. Он не изменяет политику и не требует доступа ко всему проекту. Это означает, что приложению не требуется ни одно из первых трех необходимых разрешений. Последнее — это все, что требуется, и это то, что мы реализуем в примере приложения.

Основное тело функции создает пустой набор пользователей-администраторов ( admins ), получает allow_policy с помощью get_iam_policy() и циклически перебирает все свои привязки в поисках ролей администратора App Engine:

roles/viewer
roles/editor
roles/owner
roles/appengine.appAdmin

Для каждой найденной целевой роли он сопоставляет пользователей, принадлежащих к этой роли, добавляя их к общему набору пользователей-администраторов. Он завершается возвратом всех найденных и кэшированных пользователей-администраторов в виде константы ( _ADMINS ) на весь срок службы этого экземпляра App Engine. Мы увидим, что этот звонок состоится в ближайшее время.

Добавьте следующее определение функции _get_gae_admins() в main.py чуть ниже создания экземпляра клиента Cloud NDB API ( ds_client ):

def _get_gae_admins():
    'return set of App Engine admins'
    # setup constants for calling Cloud Resource Manager API
    _, PROJ_ID = default(  # Application Default Credentials and project ID
            ['https://www.googleapis.com/auth/cloudplatformprojects.readonly'])
    rm_client = resourcemanager.ProjectsClient()
    _TARGETS = frozenset((     # App Engine admin roles
            'roles/viewer',
            'roles/editor',
            'roles/owner',
            'roles/appengine.appAdmin',
    ))

    # collate users who are members of at least one GAE admin role (_TARGETS)
    admins = set()                      # set of all App Engine admins
    allow_policy = rm_client.get_iam_policy(resource='projects/%s' % PROJ_ID)
    for b in allow_policy.bindings:     # bindings in IAM allow-policy
        if b.role in _TARGETS:          # only look at GAE admin roles
            admins.update(user.split(':', 1).pop() for user in b.members)
    return admins

Когда пользователи входят в приложение, происходит следующее:

Быстрая проверка выполняется из веб-шаблона после входа пользователя в Firebase.
Когда состояние аутентификации изменяется в шаблоне, выполняется вызов fetch() в стиле Ajax для /is_admin , обработчиком которого является следующая функция is_admin() .
Токен Firebase ID передается в теле POST функции is_admin() , которая извлекает его из заголовков и вызывает Firebase Admin SDK для его проверки. Если это действительный пользователь, извлеките его адрес электронной почты и проверьте, является ли он пользователем с правами администратора.
Затем логический результат возвращается в шаблон как успешный результат 200.

Добавьте is_admin() в main.py сразу после _get_gae_admins() :

@app.route('/is_admin', methods=['POST'])
def is_admin():
    'check if user (via their Firebase ID token) is GAE admin (POST) handler'
    id_token = request.headers.get('Authorization')
    email = auth.verify_id_token(id_token).get('email')
    return {'admin': email in _ADMINS}, 200

Весь код обеих функций необходим для репликации функций, доступных в службе Users, в частности, функции is_current_user_admin() . Этот вызов функции в Модуле 20 взял на себя всю тяжелую работу, в отличие от Модуля 21, где мы реализовали заменяющее решение. Хорошей новостью является то, что приложение больше не зависит от службы App Engine, а это означает, что вы можете переместить свои приложения в Cloud Run или другие службы. Кроме того, вы также можете изменить определение «пользователя-администратора» для своих собственных приложений, просто переключившись на нужные роли в _TARGETS , тогда как служба «Пользователи» жестко запрограммирована для ролей администратора App Engine.

Факторы проектирования: кэширование

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

Инициализация Firebase Auth и кэширование пользователей-администраторов App Engine.

Мы могли бы инициализировать Firebase Auth вверху, рядом с тем же местом, где инициализируется приложение Flask и создается клиент Cloud NDB API, но в этом не было необходимости, пока не был определен весь код администратора, где мы и находимся сейчас. Аналогично, теперь, когда _get_gae_admins() определена, вызовите ее для кэширования списка пользователей-администраторов.

Добавьте эти строки сразу под телом функции is_admin() :

# initialize Firebase and fetch set of App Engine admins
initialize_app()
_ADMINS = _get_gae_admins()

Посетите обновления модели данных

Модель данных Visit не меняется. Доступ к хранилищу данных требует явного использования диспетчера контекста клиента API Cloud NDB, ds_client.context() . В коде это означает, что вы оборачиваете вызовы Datastore как в store_visit() так и fetch_visits() внутри Python with блоков. Это обновление идентично Модулю 2. Внесите изменения следующим образом:

ДО:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    return Visit.query().order(-Visit.timestamp).fetch(limit)

ПОСЛЕ:

class Visit(ndb.Model):
    'Visit entity registers visitor IP address & timestamp'
    visitor   = ndb.StringProperty()
    timestamp = ndb.DateTimeProperty(auto_now_add=True)

def store_visit(remote_addr, user_agent):
    'create new Visit entity in Datastore'
    with ds_client.context():
        Visit(visitor='{}: {}'.format(remote_addr, user_agent)).put()

def fetch_visits(limit):
    'get most recent visits'
    with ds_client.context():
        return Visit.query().order(-Visit.timestamp).fetch(limit)

Служба пользователей App Engine работает на стороне сервера, тогда как Firebase Auth и Cloud Identity Platform — преимущественно на стороне клиента. В результате большая часть кода управления пользователями из приложения Модуля 20 перемещается в веб-шаблон Модуля 21.

В main.py веб-контекст передает в шаблон пять основных фрагментов данных. Первые четыре из перечисленных связаны с управлением пользователями и различаются в зависимости от того, вошел ли пользователь в систему или нет:

who — адрес электронной почты пользователя, если он вошел в систему, или пользователя в противном случае.
admin — значок (администратора) , если вошедший в систему пользователь является администратором.
sign — показать кнопку «Войти» или «Выйти»
link — ссылки для входа или выхода при нажатии кнопки.
visits — самые последние посещения

ДО:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)

    # put together users context for web template
    user = users.get_current_user()
    context = {  # logged in
        'who':   user.nickname(),
        'admin': '(admin)' if users.is_current_user_admin() else '',
        'sign':  'Logout',
        'link':  '/_ah/logout?continue=%s://%s/' % (
                      request.environ['wsgi.url_scheme'],
                      request.environ['HTTP_HOST'],
                  ),  # alternative to users.create_logout_url()
    } if user else {  # not logged in
        'who':   'user',
        'admin': '',
        'sign':  'Login',
        'link':  users.create_login_url('/'),
    }

    # add visits to context and render template
    context['visits'] = visits  # display whether logged in or not
    return render_template('index.html', **context)

Все управление пользователями переносится в веб-шаблон, поэтому нам остаются только посещения, возвращая основной обработчик тому, что у нас было еще в приложении Модуля 1:

ПОСЛЕ:

@app.route('/')
def root():
    'main application (GET) handler'
    store_visit(request.remote_addr, request.user_agent)
    visits = fetch_visits(10)
    return render_template('index.html', visits=visits)

Обновить веб-шаблон

Как выглядят в шаблоне все обновления из предыдущего раздела? В основном мы перенесли управление пользователями из приложения в Firebase Auth, работающую в шаблоне, и частичный порт всего этого кода, который мы перенесли в JavaScript. Мы увидели, что main.py немного сократился, поэтому ожидайте аналогичного роста в templates/index.html .

ДО:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>
</head>
<body>
<p>
Welcome, {{ who }} <code>{{ admin }}</code>
<button id="logbtn">{{ sign }}</button>
</p><hr>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

<script>
document.getElementById("logbtn").onclick = () => {
    window.location.href = '{{ link }}';
};
</script>
</body>
</html>

Замените весь веб-шаблон содержимым ниже:

ПОСЛЕ:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>

<script type="module">
// import Firebase module attributes
import {
        initializeApp
} from "https://www.gstatic.com/firebasejs/9.10.0/firebase-app.js";
import {
        GoogleAuthProvider,
        getAuth,
        onAuthStateChanged,
        signInWithPopup,
        signOut
} from "https://www.gstatic.com/firebasejs/9.10.0/firebase-auth.js";

// Firebase config:
// 1a. Go to: console.cloud.google.com/customer-identity/providers
// 1b. May be prompted to enable GCIP and upgrade from Firebase
// 2. Click: "Application Setup Details" button
// 3. Copy: 'apiKey' and 'authDomain' from 'config' variable
var firebaseConfig = {
        apiKey: "YOUR_API_KEY",
        authDomain: "YOUR_AUTH_DOMAIN",
};

// initialize Firebase app & auth components
initializeApp(firebaseConfig);
var auth = getAuth();
var provider = new GoogleAuthProvider();
//provider.setCustomParameters({prompt: 'select_account'});

// define login and logout button functions
function login() {
    signInWithPopup(auth, provider);
};

function logout() {
    signOut(auth);
};

// check if admin & switch to logout button on login; reset everything on logout
onAuthStateChanged(auth, async (user) => {
    if (user && user != null) {
        var email = user.email;
        who.innerHTML = email;
        logbtn.onclick = logout;
        logbtn.innerHTML = "Logout";
        var idToken = await user.getIdToken();
        var rsp = await fetch("/is_admin", {
                method: "POST",
                headers: {Authorization: idToken}
        });
        var data = await rsp.json();
        if (data.admin) {
            admin.style.display = "inline";
        }
    } else {
        who.innerHTML = "user";
        admin.style.display = "none";
        logbtn.onclick = login;
        logbtn.innerHTML = "Login";
    }
});
</script>
</head>

<body>
<p>
Welcome, <span id="who"></span> <span id="admin"><code>(admin)</code></span>
<button id="logbtn"></button>
</p><hr>

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

<script>
var who    = document.getElementById("who");
var admin  = document.getElementById("admin");
var logbtn = document.getElementById("logbtn");
</script>
</body>
</html>

В этом теле HTML много компонентов, поэтому давайте рассмотрим их по одному.

Импорт Firebase

Находясь в заголовке HTML-документа, после заголовка страницы, импортируйте необходимые компоненты Firebase. Компоненты Firebase теперь разбиты на несколько модулей для повышения эффективности. Код для инициализации Firebase импортируется из основного модуля приложения Firebase, а функции, которые управляют аутентификацией Firebase, Google в качестве поставщика аутентификации, входом и выходом, а также «обратным вызовом» изменения состояния аутентификации, импортируются из модуля Firebase Auth:

<!doctype html>
<html>
<head>
<title>VisitMe Example</title>

<script type="module">
// import Firebase module attributes
import {
        initializeApp
} from "https://www.gstatic.com/firebasejs/9.10.0/firebase-app.js";
import {
        GoogleAuthProvider,
        getAuth,
        onAuthStateChanged,
        signInWithPopup,
        signOut
} from "https://www.gstatic.com/firebasejs/9.10.0/firebase-auth.js";

Конфигурация Firebase

Ранее, во время настройки платформы Identity в этом руководстве, вы сохранили apiKey и authDomain из диалогового окна «Сведения о настройке приложения» . Добавьте эти значения в переменную firebaseConfig в следующем разделе. Ссылка на более подробную инструкцию предоставлена в комментариях:

// Firebase config:
// 1a. Go to: console.cloud.google.com/customer-identity/providers
// 1b. May be prompted to enable GCIP and upgrade from Firebase
// 2. Click: "Application Setup Details" button
// 3. Copy: 'apiKey' and 'authDomain' from 'config' variable
var firebaseConfig = {
        apiKey: "YOUR_API_KEY",
        authDomain: "YOUR_AUTH_DOMAIN",
};

Инициализация Firebase

В следующем разделе Firebase инициализируется с использованием этой информации о конфигурации.

// initialize Firebase app & auth components
initializeApp(firebaseConfig);
var auth = getAuth();
var provider = new GoogleAuthProvider();
//provider.setCustomParameters({prompt: 'select_account'});

Это устанавливает возможность использовать Google в качестве поставщика аутентификации и предоставляет опцию с комментариями для отображения средства выбора учетной записи, даже если в сеансе вашего браузера зарегистрирована только одна учетная запись Google. Другими словами, если у вас несколько учетных записей, вам будет представлен этот «выбор учетных записей», как и ожидалось: Однако если в сеансе участвует только один пользователь, процесс входа в систему завершается автоматически без какого-либо взаимодействия с пользователем. (Всплывающее окно появляется, а затем исчезает.) Вы можете заставить диалоговое окно выбора учетной записи отображаться для одного пользователя (вместо немедленного входа в приложение), раскомментировав строку настраиваемого параметра. Если этот параметр включен, даже при однопользовательском входе открывается средство выбора учетной записи:

Следующие строки кода представляют собой функции для нажатия кнопки входа или выхода:

// define login and logout button functions
function login() {
    signInWithPopup(auth, provider);
};

function logout() {
    signOut(auth);
};

Последний основной раздел в этом блоке <script> — это функция, которая вызывается при каждом изменении аутентификации (вход или выход).

// check if admin & switch to logout button on login; reset everything on logout
onAuthStateChanged(auth, async (user) => {
    if (user && user != null) {
        var email = user.email;
        who.innerHTML = email;
        logbtn.onclick = logout;
        logbtn.innerHTML = "Logout";
        var idToken = await user.getIdToken();
        var rsp = await fetch("/is_admin", {
                method: "POST",
                headers: {Authorization: idToken}
        });
        var data = await rsp.json();
        if (data.admin) {
            admin.style.display = "inline";
        }
    } else {
        who.innerHTML = "user";
        admin.style.display = "none";
        logbtn.onclick = login;
        logbtn.innerHTML = "Login";
    }
});
</script>
</head>

Здесь переносится код в модуле 20, определяющий, следует ли отправлять контекст шаблона «пользователь, вошедший в систему», или контекст «пользователь, вышедший из системы». Условие вверху приводит к true , если пользователь успешно вошел в систему, вызывая следующие действия:

Адрес электронной почты пользователя настроен для отображения.
Кнопка «Войти» изменится на «Выход» .
Вызов /is_admin в стиле Ajax выполняется, чтобы определить, отображать ли значок пользователя администратора (admin) .

Когда пользователь выходит из системы, выполняется предложение else для сброса всей информации о пользователе:

Имя пользователя установлено для пользователя
Любой значок администратора удален.
Кнопка выхода изменена обратно на вход.

Переменные шаблона

После завершения раздела заголовка основная часть начинается с переменных шаблона, которые заменяются элементами HTML, которые изменяются по мере необходимости:

Отображаемое имя пользователя
(admin) значок администратора (если применимо)
Кнопка входа или выхода

<body>
<p>
Welcome, <span id="who"></span> <span id="admin"><code>(admin)</code></span>
<button id="logbtn"></button>
</p><hr>

Последние посещения и переменные элемента HTML

Код последних посещений не меняется, а последний блок <script> устанавливает переменные для элементов HTML, которые изменяются при входе и выходе, перечисленных чуть выше:

<h1>VisitMe example</h1>
<h3>Last 10 visits</h3>
<ul>
{% for visit in visits %}
    <li>{{ visit.timestamp.ctime() }} from {{ visit.visitor }}</li>
{% endfor %}
</ul>

<script>
var who    = document.getElementById("who");
var admin  = document.getElementById("admin");
var logbtn = document.getElementById("logbtn");
</script>
</body>
</html>

На этом завершаются изменения, необходимые в приложении и веб-шаблоне для перехода с App Engine NDB и Users API на Cloud NDB и Identity Platform, а также для обновления до Python 3. Поздравляем с появлением нового примера приложения Модуля 21! Наша версия доступна для ознакомления в папке репозитория Module 21b .

Следующая часть лаборатории кода является необязательной (*) и предназначена только для пользователей, чьи приложения должны оставаться на Python 2. Она проведет вас через шаги, необходимые для создания работающего приложения Python 2 Module 21.

6. * Резервный порт Python 2.

Этот необязательный раздел предназначен для разработчиков, выполняющих миграцию Identity Platform, но которым необходимо продолжать работу в среде выполнения Python 2. Если вас это не беспокоит, пропустите этот раздел.

Чтобы создать рабочую версию приложения «Модуль 21» на Python 2, вам потребуется следующее:

Требования к среде выполнения : файлы конфигурации, поддерживающие Python 2, и необходимые изменения в основном приложении, чтобы избежать несовместимости с Python 3.
Незначительное изменение библиотеки: Python 2 устарел до того, как в клиентскую библиотеку Resource Manager были добавлены некоторые необходимые функции. В результате вам нужен альтернативный способ доступа к этой недостающей функциональности.

Давайте предпримем эти шаги сейчас, начиная с настройки.

Восстановить appengine_config.py

Ранее в этом руководстве вам было предложено удалить appengine_config.py поскольку он не используется средой выполнения Python 3 App Engine. Для Python 2 его необходимо не только сохранить, но и обновить модуль 20 appengine_config.py для поддержки использования встроенных сторонних библиотек , а именно grpcio и setuptools . Эти пакеты необходимы всякий раз, когда ваше приложение App Engine использует клиентские библиотеки Cloud, например библиотеки Cloud NDB и Cloud Resource Manager.

Вы сразу же добавите эти пакеты в app.yaml , но для того, чтобы ваше приложение могло получить к ним доступ, необходимо вызвать функцию pkg_resources.working_set.add_entry() из setuptools . Это позволяет скопированным (самостоятельным или поставляемым) сторонним библиотекам, установленным в папке lib , иметь возможность взаимодействовать со встроенными библиотеками.

Внесите следующие обновления в файл appengine_config.py , чтобы применить эти изменения:

ДО:

from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)

Одного этого кода недостаточно для поддержки использования setuptools и grpcio . Необходимо еще несколько строк, поэтому обновите appengine_config.py , чтобы он выглядел так:

ПОСЛЕ:

import pkg_resources
from google.appengine.ext import vendor

# Set PATH to your libraries folder.
PATH = 'lib'
# Add libraries installed in the PATH folder.
vendor.add(PATH)
# Add libraries to pkg_resources working set to find the distribution.
pkg_resources.working_set.add_entry(PATH)

Более подробную информацию об изменениях, необходимых для поддержки клиентских библиотек Cloud, можно найти в документации по миграции входящих в комплект услуг .

app.yaml

Как и в случае с appengine_config.py , файл app.yaml необходимо вернуть к файлу, поддерживающему Python 2. Начнем с исходного модуля 20 app.yaml :

ДО:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

Помимо setuptools и grpcio , как упоминалось ранее, существует зависимость (не связанная явно с миграцией Identity Platform), требующая использования клиентской библиотеки Cloud Storage , а для этого нужен еще один встроенный сторонний пакет — ssl . Добавьте все три в новый раздел libraries , выбрав «последние» доступные версии этих пакетов, в app.yaml :

ПОСЛЕ:

runtime: python27
threadsafe: yes
api_version: 1

handlers:
- url: /.*
  script: main.app

libraries:
- name: grpcio
  version: latest
- name: setuptools
  version: latest
- name: ssl
  version: latest

требования.txt

Для модуля 21 мы добавили Google Auth , Cloud NDB , Cloud Resource Manager и Firebase Admin SDK в requirements.txt Python 3.txt. Ситуация с Python 2 более сложная:

API Resource Manager предоставляет функциональные возможности политики разрешения, необходимые для примера приложения. К сожалению, эта поддержка еще не была доступна в финальной версии клиентской библиотеки Cloud Resource Manager для Python 2 . (Он доступен только в версии Python 3.)
В результате требуется альтернативный способ доступа к этой функции через API. Решение состоит в том, чтобы использовать клиентскую библиотеку Google API нижнего уровня для взаимодействия с API. Чтобы переключиться на эту клиентскую библиотеку, замените google-cloud-resource-manager пакетом google-api-python-client более низкого уровня.
Поскольку Python 2 устарел , граф зависимостей, поддерживающий Модуль 21, требует привязки определенных пакетов к определенным версиям. Некоторые пакеты необходимо вызывать, даже если они не указаны в app.yaml Python 3.

ДО:

flask

Начиная с файла requirements.txt Модуля 20, обновите его следующим образом для работающего приложения Модуля 21:

ПОСЛЕ:

grpcio==1.0.0
protobuf<3.18.0
six>=1.13.0
flask
google-gax<0.13.0
google-api-core==1.31.1
google-api-python-client<=1.11.0
google-auth<2.0dev
google-cloud-datastore==1.15.3
google-cloud-firestore==1.9.0
google-cloud-ndb
google-cloud-pubsub==1.7.0
firebase-admin

Номера пакетов и версий будут обновляться в репозитории по мере изменения зависимостей, но этого app.yaml достаточно для работающего приложения на момент написания этой статьи.

Другие обновления конфигурации

Если вы еще не удалили папку lib созданную ранее в этой лаборатории кода, сделайте это сейчас. Используя недавно обновленный requirements.txt , введите знакомую команду, чтобы установить эти требования в lib :

pip install -t lib -r requirements.txt  # or pip2

Если в вашей системе разработки установлены Python 2 и 3, возможно, вам придется использовать pip2 вместо pip .

Изменить код приложения

К счастью, большинство необходимых изменений находятся в файлах конфигурации. Единственное изменение, необходимое в коде приложения, — это незначительное обновление для использования клиентской библиотеки Google API нижнего уровня вместо клиентской библиотеки Resource Manager для доступа к API. Веб-шаблон templates/index.html не требует никаких обновлений.

Обновление импорта и инициализации

Замените клиентскую библиотеку Resource Manager ( google.cloud.resourcemanager ) клиентской библиотекой Google API ( googleapiclient.discovery ), как показано ниже:

ДО:

from flask import Flask, render_template, request
from google.auth import default
from google.cloud import ndb, resourcemanager
from firebase_admin import auth, initialize_app

ПОСЛЕ:

from flask import Flask, render_template, request
from google.auth import default
from google.cloud import ndb
from googleapiclient import discovery
from firebase_admin import auth, initialize_app

Поддержка пользователей с правами администратора App Engine

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

Код Python 2 требует использования как учетных данных, так и идентификатора проекта, возвращаемого из google.auth.default() . Учетные данные не используются в Python 3, поэтому они были присвоены общей фиктивной переменной подчеркивания ( _ ). Поскольку это необходимо для версии Python 2, измените подчеркивание на CREDS . Кроме того, вместо создания клиента API Resource Manager вы создадите конечную точку службы API, по концепции аналогичную клиенту API, поэтому мы сохраняем то же имя переменной ( rm_client ). Единственное отличие состоит в том, что для создания экземпляра конечной точки службы требуются учетные данные ( CREDS ).

Эти изменения отражены в коде ниже:

ДО:

_, PROJ_ID = default(  # Application Default Credentials and project ID
        ['https://www.googleapis.com/auth/cloudplatformprojects.readonly'])
rm_client = resourcemanager.ProjectsClient()

ПОСЛЕ:

CREDS, PROJ_ID = default(  # Application Default Credentials and project ID
        ['https://www.googleapis.com/auth/cloud-platform'])
rm_client = discovery.build('cloudresourcemanager', 'v1', credentials=CREDS)

Другое отличие состоит в том, что клиентская библиотека Resource Manager возвращает объекты политики разрешения, которые используют нотацию атрибутов с точками, в то время как клиентская библиотека более низкого уровня возвращает словари Python, в которых используются квадратные скобки ( [ ] ), например, используйте binding.role для Клиентская библиотека Resource Manager в сравнении с binding['role'] для библиотеки нижнего уровня. В первом также используются имена «underscore_separated», а в библиотеке нижнего уровня — имена «CamelCased», а также немного другой способ передачи параметров API.

Эти различия в использовании показаны ниже:

ДО:

allow_policy = rm_client.get_iam_policy(resource='projects/%s' % PROJ_ID)
for b in allow_policy.bindings:     # bindings in IAM allow-policy
    if b.role in _TARGETS:          # only look at GAE admin roles
        admins.update(user.split(':', 1).pop() for user in b.members)

ПОСЛЕ:

allow_policy = rm_client.projects().getIamPolicy(resource=PROJ_ID).execute()
for b in allow_policy['bindings']:  # bindings in IAM allow-policy
    if b['role'] in _TARGETS:       # only look at GAE admin roles
        admins.update(user.split(':', 1).pop() for user in b['members'])

Объединив все эти изменения, замените _get_gae_admins() Python 3 эквивалентной версией Python 2:

def _get_gae_admins():
    'return set of App Engine admins'
    # setup constants for calling Cloud Resource Manager API
    CREDS, PROJ_ID = default(  # Application Default Credentials and project ID
            ['https://www.googleapis.com/auth/cloud-platform'])
    rm_client = discovery.build('cloudresourcemanager', 'v1', credentials=CREDS)
    _TARGETS = frozenset((     # App Engine admin roles
            'roles/viewer',
            'roles/editor',
            'roles/owner',
            'roles/appengine.appAdmin',
    ))

    # collate users who are members of at least one GAE admin role (_TARGETS)
    admins = set()                      # set of all App Engine admins
    allow_policy = rm_client.projects().getIamPolicy(resource=PROJ_ID).execute()
    for b in allow_policy['bindings']:  # bindings in IAM allow-policy
        if b['role'] in _TARGETS:       # only look at GAE admin roles
            admins.update(user.split(':', 1).pop() for user in b['members'])
    return admins

Функция is_admin() не требует никаких обновлений, поскольку она использует уже обновленную функцию _get_gae_admins() .

На этом завершаются изменения, необходимые для обратного переноса приложения модуля 21 модуля Python 3 в Python 2. Поздравляем с появлением обновленного примера приложения модуля 21! Весь код вы найдете в папке репозитория Module 21a .

7. Подведение итогов/очистка

Последние шаги в лаборатории кода — убедиться, что участники (пользователи или учетные записи служб), запускающие это приложение, имеют необходимые разрешения для этого, а затем развернуть приложение, чтобы убедиться, что оно работает должным образом, и изменения отражаются в выходных данных.

Возможность чтения IAM-политики разрешений

Ранее мы познакомили вас с четырьмя ролями, необходимыми для признания в качестве пользователя-администратора App Engine, но теперь есть пятая, с которой необходимо ознакомиться:

roles/viewer
roles/editor
roles/owner
roles/appengine.appAdmin
roles/resourcemanager.projectIamAdmin (для участников, имеющих доступ к политике разрешения IAM)

Роль roles/resourcemanager.projectIamAdmin позволяет принципалам определять, является ли конечный пользователь членом какой-либо роли администратора App Engine. Без членства в roles/resourcemanager.projectIamAdmin вызовы API Cloud Resource Manager для получения политики разрешения завершатся ошибкой.

Вам не нужно предпринимать здесь каких-либо явных действий, поскольку ваше приложение будет работать под учетной записью службы App Engine по умолчанию , которой автоматически предоставляется членство в этой роли. Даже если вы используете учетную запись службы по умолчанию на этапе разработки, мы настоятельно рекомендуем создать и использовать управляемую пользователем учетную запись службы с минимальными разрешениями, необходимыми для правильной работы вашего приложения. Чтобы предоставить членство такой учетной записи службы, выполните следующую команду:

$ gcloud projects add-iam-policy-binding PROJ_ID --member="serviceAccount:USR_MGD_SVC_ACCT@PROJ_ID.iam.gserviceaccount.com" --role=roles/resourcemanager.projectIamAdmin

PROJ_ID — это идентификатор облачного проекта, а USR_MGD_SVC_ACCT@PROJ_ID.iam.gserviceaccount.com — это управляемая пользователем учетная запись службы, которую вы создаете для своего приложения. Эта команда выводит обновленную политику IAM для вашего проекта, где вы можете подтвердить, что учетная запись службы имеет членство в roles/resourcemanager.projectIamAdmin . Дополнительную информацию смотрите в справочной документации . Повторяю: вам не нужно вводить эту команду в этой лаборатории кода, но сохраните ее как справочник для модернизации ваших собственных приложений.

Развертывание и проверка приложения

Загрузите свое приложение в облако с помощью стандартной команды gcloud app deploy . После развертывания вы должны увидеть функциональность, почти идентичную приложению Module 20, за исключением того, что вы успешно заменили службу пользователей Engine App на платформу Cloud Identity (и Firebase Auth) для управления пользователями:

Одно отличие, которое вы заметите по сравнению с модулем 20, заключается в том, что щелчок по входу в систему приводит к всплыванию вместо перенаправления, снятого в некоторых из приведенных ниже скриншотов. Как и модуль 20, однако, поведение немного отличается в зависимости от того, сколько учетных записей Google было зарегистрировано в браузере.

Если в браузере или единого пользователя, который еще не вписался пользователи, не зарегистрировались, появится общее всплывающее окно вступительного входа в Google:

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

Некоторые разработчики могут захотеть предоставить пикер учетной записи, даже для одного пользователя:

Чтобы реализовать это, расстроен provider.setCustomParameters({prompt: 'select_account'}); Линия в веб -шаблоне, как описано ранее.

Если есть несколько пользователей, появляется диалоговое окно для формирования учетной записи (см. Ниже). Если еще не подписан, пользователя будет предложено. Если уже подписано, всплывающее окно исчезает, и приложение переходит в подписанное состояние.

Состояние подписанного модуля 21 выглядит идентично пользовательскому интерфейсу модуля 20:

То же самое относится и к тому, когда пользователь администратора подписал:

В отличие от модуля 21, модуль 20 всегда обращается к логике для содержимого веб-шаблона из приложения (код на стороне сервера). Недостаток модуля 20 состоит в том, что одно посещение зарегистрировано, когда конечный пользователь попадает в приложение в первый раз, а другое зарегистрируется, когда пользовательские знаки.

Для модуля 21 логика входа в систему происходит только в веб-шаблоне (код на стороне клиента). Не существует необходимой поездки на стороне сервера, чтобы определить, какой контент отобразить. Единственный вызов, сделанный на сервере,-это проверка для пользователей администратора после знаков конечного пользователя. Это означает, что входы и входы не регистрируют дополнительные посещения, поэтому самый последний список посещений остается постоянным для действий по управлению пользователями. Обратите внимание на скриншоты выше, отображают один и тот же набор из четырех посещений по нескольким входам пользователей.

Скриншоты модуля 20 демонстрируют «ошибку двойного визуализации» в начале этого CodeLab. Отдельные журналы посещений отображаются для каждого входа или регистрации. Проверьте метки времени последнего посещения для каждого скриншота, показывающего хронологический заказ.

Очистить

Общий

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

Для полной информации: развертывание на бессерверной вычислительной платформе Google Cloud, такой как App Engine, требует незначительных затрат на сборку и хранение . Cloud Build имеет собственную бесплатную квоту, как и Cloud Storage . Хранение этого изображения использует часть этой квоты. Однако вы можете жить в регионе, где нет такого уровня бесплатного пользования, поэтому следите за использованием своего хранилища, чтобы минимизировать потенциальные затраты. Конкретные «папки» облачного хранилища, которые вам следует просмотреть, включают:

console.cloud.google.com/storage/browser/LOC.artifacts.PROJECT_ID.appspot.com/containers/images
console.cloud.google.com/storage/browser/staging.PROJECT_ID.appspot.com
Приведенные выше ссылки зависят от вашего PROJECT_ID и LOC , например, « us », если ваше приложение размещено в США.

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

Специально для этой кодовой лаборатории

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

Служба хранилища данных App Engine предоставляется Cloud Datastore (Cloud Firestore в режиме хранилища данных), который также имеет уровень бесплатного пользования; дополнительную информацию см. на странице цен .
Использование платформы Cloud Identity имеет некоторый уровень «свободного», в зависимости от того, какие из ее услуг вы используете. Смотрите его страницу ценообразования для получения более подробной информации.
Использование API Manager Resource Resource Manager бесплатно по большей части в соответствии с его страницей ценообразования .

Следующие шаги

Помимо этого руководства, следует рассмотреть и другие модули миграции, направленные на отказ от устаревших комплексных услуг:

Модуль 2. Переход с App Engine ndb на Cloud NDB.
Модули 7-9 : мигрируйте из очереди задач App Engine (задачи толкания) в облачные задачи
Модули 12–13 : миграция с Memcache App Engine на Cloud Memorystore.
Модули 15–16 : миграция из App Engine Blobstore в облачное хранилище.
Модули 18–19 : переход из очереди задач App Engine (задачи по запросу) в Cloud Pub/Sub.

App Engine больше не является единственной бессерверной платформой в Google Cloud. Если у вас есть небольшое приложение App Engine или приложение с ограниченной функциональностью, и вы хотите превратить его в автономный микросервис, или вы хотите разбить монолитное приложение на несколько повторно используемых компонентов, это веские причины рассмотреть возможность перехода на облачные функции . Если контейнеризация стала частью вашего рабочего процесса разработки приложений, особенно если он состоит из конвейера CI/CD (непрерывная интеграция/непрерывная доставка или развертывание), рассмотрите возможность перехода на Cloud Run . Эти сценарии рассматриваются в следующих модулях:

Миграция с App Engine на облачные функции: см. Модуль 11.
Миграция с App Engine на Cloud Run: см. Модуль 4 , чтобы контейнеризировать приложение с помощью Docker, или Модуль 5 , чтобы сделать это без контейнеров, знаний Docker или Dockerfile s.

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

Независимо от того, какой модуль миграции вы рассматриваете следующим, весь контент Serverless Migration Station (лаборатории кода, видео, исходный код [при наличии]) можно получить в его репозитории с открытым исходным кодом . README репозитория также содержит рекомендации относительно того, какие миграции следует учитывать, а также любой соответствующий «порядок» модулей миграции.

8. Дополнительные ресурсы

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

Проблемы/отзывы Codelabs

Если вы обнаружите какие-либо проблемы с этой кодовой лабораторией, сначала найдите свою проблему, прежде чем подавать заявку. Ссылки для поиска и создания новых задач:

Миграционные ресурсы

Ссылки на папки репо для модуля 20 (запуск) и модуля 21 (отделка) можно найти в таблице ниже.

Кодлаб	Питон 2	Питон 3
Модуль 20	код	(н/д)
Модуль 21 (этот коделаб)	код	код

Интернет-ссылки

Ниже приведены ресурсы, относящиеся к этому руководству:

Платформа облачной идентификации и рынок облаков

Менеджер облачных ресурсов, Cloud IAM, Firebase Admin SDK

Страница продукта менеджера ресурсов
Информация о ценах на менеджер ресурсов
Клиентская библиотека управления ресурсами
Обзор Cloud IAM (роли, разрешение на политику и т. Д.)
Admin SDK Firebase (Python)

Пользователи двигателя приложений, App Engine NDB, Cloud NDB, Cloud Datastore

Другие ссылки на модуль миграции

Введение модуля миграции
Все ресурсы "без сервера миграционной станции"
Переход на документацию Python 3
Миграционный модуль 17 "Используя комплексные службы во втором поколении" Codelab "Codelab
Миграционный модуль 20 "Добавить службу пользователей приложений для приложений в колбу" CodeLab

Приложение двигателя миграция

Платформа App Engine

Облачный SDK

Google Cloud SDK
Cloud SDK gcloud Commandline
Включение (и отключение) Google API
Cloud Console API Manager (включить/отключить API)
Включение Google API с gcloud
Перечисление Google API с gcloud

Другая информация об облаке

Видео

Лицензия

Эта работа распространяется под лицензией Creative Commons Attribution 2.0 Generic License.

Миграция со службы пользователей App Engine на платформу Cloud Identity (модуль 21).

1. Обзор

Вы узнаете, как

Что вам понадобится

Опрос

Как вы будете использовать этот урок?

Как бы вы оценили свой опыт работы с Python?

Как бы вы оценили свой опыт использования сервисов Google Cloud?

2. Предыстория

3. Настройка/Предварительная работа

1. Проект установки

2. Получите базовый образец приложения.

3. (Повторное) развертывание и проверка базового приложения.

4. Включите новые API/сервисы Google Cloud.

Введение

Расходы

Из облачной консоли

Из командной строки

Включение и настройка Cloud Identity Platform (только облачная консоль)

4. Обновить конфигурацию

appengine_config.py

требования.txt

app.yaml

Другие обновления конфигурации

5. Измените код приложения.

Обновление импорта и инициализации

Поддержка пользователей с правами администратора App Engine

Инициализация Firebase Auth и кэширование пользователей-администраторов App Engine.

Посетите обновления модели данных

Переместить логику входа пользователя в веб-шаблон

Обновить веб-шаблон

Импорт Firebase

Конфигурация Firebase

Инициализация Firebase

Функции входа и выхода из системы

Действия входа и выхода

Переменные шаблона

Последние посещения и переменные элемента HTML

6. * Резервный порт Python 2.

Восстановить appengine_config.py

app.yaml

требования.txt

Другие обновления конфигурации

Изменить код приложения

Обновление импорта и инициализации

Поддержка пользователей с правами администратора App Engine

7. Подведение итогов/очистка

Возможность чтения IAM-политики разрешений

Развертывание и проверка приложения

Очистить

Общий

Специально для этой кодовой лаборатории

Следующие шаги

8. Дополнительные ресурсы

Проблемы/отзывы Codelabs

Миграционные ресурсы

Интернет-ссылки

Платформа облачной идентификации и рынок облаков

Менеджер облачных ресурсов, Cloud IAM, Firebase Admin SDK

Пользователи двигателя приложений, App Engine NDB, Cloud NDB, Cloud Datastore

Другие ссылки на модуль миграции

Приложение двигателя миграция

Платформа App Engine

Облачный SDK

Другая информация об облаке

Видео

Лицензия