Автор оригинала: Philippe Sevestre.
1. Обзор
В предыдущих статьях мы рассказывали об основах Hipster и о том, как использовать его для создания приложения на основе микросервисов .
В этом уроке мы рассмотрим учетную запись пользователя и службу авторизации JHipster — UAA для краткости — и как использовать ее для защиты полноценного приложения микросервиса на основе JHispter. Еще лучше, все это может быть достигнуто без написания одной строки кода !
2. Основные функции UAA
Важной особенностью приложений, которые мы создали в наших предыдущих статьях, является то, что учетные записи пользователей были их неотъемлемой частью. Теперь это нормально, когда у нас есть одно приложение, но что, если мы хотим поделиться учетными записями пользователей между несколькими приложениями, созданными JHipster? Вот тут-то и появляются хипстеры UAA.
Hipsters UAA-это микросервис, который создается, развертывается и запускается независимо от других служб в нашем приложении . Он служит в качестве:
- Сервер авторизации OAuth2, основанный на реализации Spring Boot
- Сервер управления удостоверениями, предоставляющий API CRUD учетной записи пользователя
Hipster UAA также поддерживает типичные функции входа в систему, такие как саморегистрация и “запомни меня”. И, конечно же, он полностью интегрируется с другими сервисами JHipster.
3. Настройка среды разработки
Прежде чем приступить к какой-либо разработке, мы должны сначала убедиться, что в нашей среде созданы все необходимые условия. Помимо всех инструментов, описанных в нашей статье “Введение в JHipster”, нам понадобится работающий реестр JHipster. В качестве краткого резюме, служба реестра позволяет различным службам, которые мы создадим, находить и общаться друг с другом.
Полная процедура создания и запуска реестра описана в разделе 4.1 нашей статьи JHipster с архитектурой микросервиса поэтому мы не будем повторять ее здесь. Образ Docker также доступен и может быть использован в качестве альтернативы.
4. Создание нового сервиса JHipster UAA
Давайте создадим наш сервис UAA с помощью утилиты командной строки Hipster:
$ mkdir uaa $ cd uaa $ jhipster
Первый вопрос, на который мы должны ответить, – это тип приложения, которое мы хотим создать. Используя клавиши со стрелками, мы выберем опцию “Hipster UAA (для аутентификации OAuth2 микросервиса)” .:
Затем нам будет предложено задать несколько вопросов, касающихся конкретных деталей, касающихся сгенерированной службы, таких как имя приложения, порт сервера и обнаружение службы:
По большей части ответы по умолчанию в порядке. Что касается базового имени приложения, которое влияет на многие сгенерированные артефакты , мы выбрали “uaa” (нижний регистр) — разумное имя. Мы можем поиграть с другими значениями, если захотим, но это не изменит основные функции созданного проекта.
После ответа на эти вопросы JHipster создаст все файлы проекта и установит зависимости npm package (которые на самом деле не используются в данном случае).
Теперь мы можем использовать локальный скрипт Maven для создания и запуска нашей службы UAA:
$ ./mvnw ... build messages omitted 2018-10-14 14:07:17.995 INFO 18052 --- [ restartedMain] com.baeldung.jhipster.uaa.UaaApp : ---------------------------------------------------------- Application 'uaa' is running! Access URLs: Local: http://localhost:9999/ External: http://192.168.99.1:9999/ Profile(s): [dev, swagger] ---------------------------------------------------------- 2018-10-14 14:07:18.000 INFO 18052 --- [ restartedMain] com.baeldung.jhipster.uaa.UaaApp : ---------------------------------------------------------- Config Server: Connected to the JHipster Registry config server! ----------------------------------------------------------
Ключевым сообщением, на которое следует обратить внимание, является сообщение о том, что UAA подключен к реестру JHipster. Это сообщение указывает на то, что UAA смог зарегистрироваться и будет доступен для обнаружения другими микросервисами и шлюзами.
5. Тестирование сервиса UAA
Поскольку сгенерированная служба UAA сама по себе не имеет пользовательского интерфейса, мы должны использовать прямые вызовы API, чтобы проверить, работает ли она должным образом.
Есть две функции, которые мы должны убедиться, что они работают, прежде чем использовать их с другими частями или нашей системой: Генерация токенов OAuth2 и поиск учетной записи.
Во-первых, давайте получим новый токен из нашей конечной точки OAuth Uas , используя простую команду curl :
$ curl -X POST --data \ "username=user&password=user&grant_type=password&scope=openid" \ http://web_app:[email protected]:9999/oauth/token
Здесь мы использовали поток password grant , используя две пары учетных данных. В этом потоке мы отправляем учетные данные клиента, используя базовую аутентификацию HTTP, которую мы кодируем непосредственно в URL-адресе.
Учетные данные конечного пользователя отправляются как часть тела, используя стандартные параметры имени пользователя и пароля. Мы также используем учетную запись пользователя с именем “пользователь” , которая по умолчанию доступна в тестовом профиле.
Предполагая, что мы правильно предоставили все детали, мы получим ответ, содержащий маркер доступа и маркер обновления:
{ "access_token" : "eyJh...(token omitted)", "token_type" : "bearer", "refresh_token" : "eyJ...(token omitted)", "expires_in" : 299, "scope" : "openid", "iat" : 1539650162, "jti" : "8066ab12-6e5e-4330-82d5-f51df16cd70f" }
Теперь мы можем использовать возвращенный access_token для получения информации для связанной учетной записи с помощью учетной записи ресурса , который доступен в сервисе UAA:
$ curl -H "Authorization: Bearer eyJh...(access token omitted)" \ http://localhost:9999/api/account { "id" : 4, "login" : "user", "firstName" : "User", "lastName" : "User", "email" : "[email protected]", "imageUrl" : "", "activated" : true, "langKey" : "en", "createdBy" : "system", "createdDate" : "2018-10-14T17:07:01.336Z", "lastModifiedBy" : "system", "lastModifiedDate" : null, "authorities" : [ "ROLE_USER" ] }
Пожалуйста, обратите внимание, что мы должны выполнить эту команду до истечения срока действия маркера доступа . По умолчанию служба UAA выдает токены, действительные в течение пяти минут, что является разумным значением для производства.
Мы можем легко изменить срок службы допустимых токенов, отредактировав файл application-.yml , соответствующий профилю, под которым мы запускаем приложение, и установив ключ uaa.web-client-configuration.access-token-validity-in-seconds . Файлы настроек находятся в каталоге src/main/resources/config нашего проекта UAA.
6. Создание шлюза с поддержкой UAA
Теперь, когда мы уверены, что наш сервис UAA и реестр услуг работают, давайте создадим экосистему для их взаимодействия. К концу мы добавим:
- Интерфейс на основе углового интерфейса
- Серверная часть микросервиса
- Шлюз API, который противостоит обоим этим
Давайте на самом деле начнем со шлюза, так как это будет служба, которая будет вести переговоры с UAA для аутентификации. Он будет размещать наше интерфейсное приложение и направлять запросы API к другим микросервисам.
Еще раз, мы будем использовать инструмент командной строки Hipster внутри вновь созданного каталога:
$ mkdir gateway $ cd gateway $ jhipster
Как и прежде, мы должны ответить на несколько вопросов, чтобы сгенерировать проект. Важными из них являются следующие:
- Тип приложения : должен быть “Шлюз микросервисов”
- Имя приложения: На этот раз мы будем использовать “шлюз”
- Обнаружение службы : Выберите “Реестр хипстеров”
- Тип аутентификации: Мы должны выбрать опцию “Аутентификация с сервером JHipster UAA” здесь
- Фреймворк пользовательского интерфейса: Давайте выберем “Angular 6”
Как только Hipster создаст все свои артефакты, мы сможем построить и запустить шлюз с помощью предоставленного скрипта Maven-оболочки:
$ ./mwnw ... many messages omitted ---------------------------------------------------------- Application 'gateway' is running! Access URLs: Local: http://localhost:8080/ External: http://192.168.99.1:8080/ Profile(s): [dev, swagger] ---------------------------------------------------------- 2018-10-15 23:46:43.011 INFO 21668 --- [ restartedMain] c.baeldung.jhipster.gateway.GatewayApp : ---------------------------------------------------------- Config Server: Connected to the JHipster Registry config server! ----------------------------------------------------------
С помощью приведенного выше сообщения мы можем получить доступ к вашему приложению, указав в вашем браузере http://localhost:8080 , на котором должна отображаться сгенерированная по умолчанию домашняя страница:
Давайте продолжим и войдем в ваше приложение, перейдя в пункт меню Учетная запись > Вход . Мы будем использовать admin/admin в качестве учетных данных, которые JHipster создает автоматически по умолчанию. Все идет хорошо, на странице приветствия появится сообщение, подтверждающее успешный вход в систему:
Во-первых, шлюз отправил наши учетные данные в конечную точку токена OAuth2 UAA, которая проверила их и сгенерировала ответ, содержащий токен доступа и обновления JWT. Затем шлюз взял эти токены и отправил их обратно в браузер в виде файлов cookie.
Затем угловой интерфейс вызвал /uaa/api/учетную запись API, который в очередной раз шлюз переадресовал в UAA. В этом процессе шлюз принимает файл cookie, содержащий маркер доступа, и использует его значение для добавления заголовка авторизации в запрос.
При необходимости мы можем увидеть весь этот поток в мельчайших деталях, проверив журналы как UAA, так и шлюза. Мы также можем получить полные данные на уровне проводов, установив уровень org.apache.http.wire logger для отладки.
7. Создание микросервиса с поддержкой UAA
Теперь, когда наша среда приложений запущена и запущена, пришло время добавить в нее простой микросервис. Мы создадим микросервис “котировки”, который предоставит полный API REST, позволяющий нам создавать, запрашивать, изменять и удалять набор котировок акций. Каждая цитата будет иметь только три свойства:
- Торговый символ котировок
- Его цена, и
- Отметка времени последней сделки
Давайте вернемся к нашему терминалу и воспользуемся инструментом командной строки Hipster для создания нашего проекта:
$ mkdir quotes $ cd quotes $ jhipster
На этот раз мы попросим JHipster создать Микросервисное приложение , которое мы назовем “кавычки”. Эти вопросы похожи на те, на которые мы отвечали раньше. Мы можем сохранить значения по умолчанию для большинства из них, за исключением этих трех:
- Обнаружение службы: Выберите “Реестр хипстеров”, так как мы уже используем его в нашей архитектуре
- Путь к приложению UAA: Поскольку мы храним все каталоги проектов в одной папке, это будет ../uaa (если мы, конечно, не изменили его)
- Тип аутентификации: Выберите “Сервер Hipster UAA”
Вот как будет выглядеть типичная последовательность ответов в нашем случае:
Как только Хипстер закончит генерировать проект, мы сможем продолжить и построить его:
$ mvnw ... many, many messages omitted ---------------------------------------------------------- Application 'quotes' is running! Access URLs: Local: http://localhost:8081/ External: http://192.168.99.1:8081/ Profile(s): [dev, swagger] ---------------------------------------------------------- 2018-10-19 00:16:05.581 INFO 16092 --- [ restartedMain] com.baeldung.jhipster.quotes.QuotesApp : ---------------------------------------------------------- Config Server: Connected to the JHipster Registry config server! ---------------------------------------------------------- ... more messages omitted
Сообщение “Подключено к серверу конфигурации реестра Hipster!” – это то, что мы ищем здесь. Его присутствие говорит нам о том, что микросервис зарегистрировался в реестре, и благодаря этому шлюз сможет направлять запросы на наш ресурс “котировки” и отображать его в удобном пользовательском интерфейсе, как только мы его создадим. Поскольку мы используем архитектуру микросервиса, мы разделили эту задачу на две части:
- Создайте серверную службу ресурса “котировки”
- Создайте пользовательский интерфейс “котировки” в интерфейсе (часть проекта шлюза)
7.1. Добавление ресурса котировок
Во — первых, нам нужно убедиться, что приложение микросервиса quotes остановлено -мы можем нажать CTRL-C в том же окне консоли, которое мы ранее использовали для его запуска.
Теперь давайте добавим объект в проект с помощью инструмента Hipsters. На этот раз мы будем использовать команду import-jdl , которая избавит нас от утомительного и подверженного ошибкам процесса предоставления всех деталей по отдельности. Для получения дополнительной информации о формате JDL, пожалуйста, обратитесь к полной ссылке на JDL .
Затем мы создаем текстовый файл с именем quotes.jh , содержащий наше Quote определение сущности , а также некоторые директивы генерации кода:
entity Quote { symbol String required unique, price BigDecimal required, lastTrade ZonedDateTime required } dto Quote with mapstruct paginate Quote with pagination service Quote with serviceImpl microservice Quote with quotes filter Quote clientRootFolder Quote with quotes
Теперь мы можем импортировать это определение сущности в наш проект:
$ jhipster import-jdl quotes.jh
Примечание: во время импорта Хипстер будет жаловаться на конфликт при применении изменений к Примечание: во время импорта Хипстер будет жаловаться на конфликт при применении изменений к файл. Мы можем смело выбирать переписывать вариант в данном случае.
Теперь мы можем снова создать и запустить наш микросервис, используя mvnw. Как только он будет запущен, мы можем убедиться, что шлюз выбирает новый маршрут доступа к представлению Шлюз , доступному из меню Администрирование . На этот раз мы видим, что есть запись для маршрута “/кавычки/**” , которая показывает, что серверная часть готова к использованию пользовательским интерфейсом.
7.2. Добавление пользовательского интерфейса котировок
Наконец, давайте создадим пользовательский интерфейс CRUD в проекте шлюза, который мы будем использовать для доступа к нашим котировкам. Мы будем использовать тот же файл JDL из проекта микросервиса “quotes” для создания компонентов пользовательского интерфейса и импортируем его с помощью команды JHipster import-jdl :
$ jhipster import-jdl ../jhipster-quotes/quotes.jh ...messages omitted ? Overwrite webpack\webpack.dev.js? y ... messages omitted Congratulations, JHipster execution is complete!
Во время импорта JHipster несколько раз запросит действия, которые он должен предпринять в отношении конфликтующих файлов. В нашем случае мы можем просто перезаписать существующие ресурсы, так как мы не делали никаких настроек.
Теперь мы можем перезапустить шлюз и посмотреть, чего мы достигли. Давайте направим наш браузер на шлюз по адресу http://localhost:8080 , убедившись, что мы обновили его содержимое. В меню Entities теперь должна быть новая запись для ресурса Quotes :
При нажатии на этот пункт меню открывается экран Котировки список:
Как и ожидалось, список пуст — мы еще не добавили никаких котировок! Давайте попробуем добавить его, нажав кнопку “Создать новую цитату” в правом верхнем углу этого экрана, которая приведет нас к форме создания/редактирования:
Мы видим, что сгенерированная форма имеет все ожидаемые функции:
- Обязательные поля отмечены красным индикатором, который после заполнения становится зеленым
- Поля даты/времени и числовые поля используют собственные компоненты для ввода данных
- Мы можем отменить это действие, которое оставит данные неизменными, или сохранить нашу новую или измененную сущность
После заполнения этой формы и нажатия кнопки Сохранить, мы увидим результаты на экране списка. Теперь мы можем видеть новый Кавычки экземпляр в таблице данных:
Как администратор, мы также имеем доступ к пункту меню API , который ведет нас к стандартному порталу разработчиков API Swagger. На этом экране мы можем выбрать один из доступных API для выполнения:
- по умолчанию: Собственный API шлюза, отображающий доступные маршруты
- uaa : API учетных записей и пользователей
- котировки: API котировок
8. Следующие шаги
Приложение, которое мы создали до сих пор, работает так, как ожидалось, и обеспечивает прочную основу для дальнейшего развития. Нам, безусловно, также потребуется написать некоторый (или много) пользовательский код, в зависимости от сложности наших требований. Некоторые области, которые, вероятно, потребуют некоторой работы, являются:
- Настройка внешнего вида пользовательского интерфейса: Это обычно довольно просто из-за того, как структурировано интерфейсное приложение — мы можем пройти долгий путь, просто поиграв с CSS и добавив несколько изображений
- Изменения в репозитории пользователей: В некоторых организациях уже есть какой — то внутренний репозиторий пользователей (например, каталог LDAP) – это потребует изменений в UAA, но самое приятное то, что нам нужно изменить его только один раз
- Более тонкая авторизация для сущностей: Стандартная модель безопасности, используемая серверной частью сгенерированной сущности, не имеет какой-либо защиты на уровне экземпляра и/или на уровне поля -разработчик должен добавить эти ограничения на соответствующем уровне (API или служба, в зависимости от случая)
Даже с учетом этих замечаний использование такого инструмента, как JHispter, может очень помочь при разработке нового приложения. Это принесет с собой прочную основу и может поддерживать хороший уровень согласованности в нашей кодовой базе по мере развития системы и разработчиков.
9. Заключение
В этой статье мы показали, как использовать JHispter для создания рабочего приложения на основе архитектуры микросервисов и сервера UAA JHipster. Мы добились этого , не написав ни одной строки кода Java , что весьма впечатляет.
Как обычно, полный код проектов, представленных в этой статье, доступен в нашем репозитории GitHub .