Как пользователь Jhipster Gateway может получить объекты из Сервиса ТОЛЬКО для вошедшего в систему пользователя

Question

Я использую микросервисы jhipster для создания своего проекта под названием Sport Stat.Я использовал jhipster для создания следующих микросервисов только для весенней загрузки:

• PlayerStatService
• LeagueService

В PlayerStatService есть несколько объектов, таких как Sport, Skill, Плеер и тд.У каждого игрока может быть список сессий, целей и т. Д.

Спорт и навыки предопределены заранее.

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

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

Я знаю, что это можно легко использовать, если это монолитное приложение.

Проблема: поскольку пользователь генерируется jhipster на шлюзе, а Player на PlayerStatService, я не могу создать какие-либо отношения между ними.Я получаю эту ошибку.

Ваша сущность не может иметь отношения с Пользователем, потому что это сущность шлюза

Мой вопрос: возможно ли достичь такой цели с помощьюсгенерированные классы и объекты (Сервис, Репозиторий)?

Если нет, то как бы вы предложили, например: ограничить пользователей возможностью получать ТОЛЬКО своих собственных игроков?Когда вы вызываете PlayerStatService RestAPI, чтобы получить игроков, как вы предлагаете мне включить зарегистрированного пользователя в мой запрос на уровне хранилища?

РЕДАКТИРОВАНИЕ: Я использую JWT в качестве аутентификации

Answer 1

Это не может быть сделано в шлюзе, это должно быть сделано в сервисах и в идеале только на основе данных, содержащихся в токене: предмет, роли или другие утверждения, чтобы вашим службам не нужно было запрашивать ваш шлюз или поставщика аутентификации.

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

Роли также полезны дляограничьте доступ, но если их недостаточно для моделирования того, что пользователь входит в команду, вы можете добавить team_id в качестве требования к своему токену.Таким образом, вы можете легко определить тренера, потому что у него / него есть ROLE_COACH и в какой команде он / она играет эту роль.