Здравствуйте!
Возникла необходимость генерировать oauth-токены в модуле core, но описанный в документации способ с OAuthTokenIssuer работает только из модуля web. Есть ли какие-нибудь способы использовать OAuthTokenIssuer в модуле core? Или может быть токен, который потом CUBA успешно примет при встроенной авторизации, можно сгенерировать каким-нибудь другим способом?
Добрый день,
А какую задачу вы решаете? Просто, обычно такие токены нужны для доступа к API, поэтому нужный класс и вынесен в модуль web.
Да, на первый взгляд оно конечно логично: web-токен должен порождаться web-api модулем. Но на самом деле можно придумать множество вариантов, где это правило не обязано соблюдаться. К примеру, в мудрёной микросервисной архитектуре web-токен может генерироваться где-то в недрах всех этих сервисов, и, прежде чем дойти до получателя, он пройдёт по цепочке из нескольких звеньев-приложений. В моём же случае всё чуть проще, мне нужно отдавать один и тот же web-токен как на REST-запросы, так и на gRPC-методы, а корневые обработчики всего этого добра, очевидно, располагаются в модуле core. Не буду рассуждать на тему того, насколько это архитектурно правильно, но что имеем, с тем и работаем.
И, судя по всему, из-за этих весьма сомнительных ограничений придётся руками генерировать какие-то альтернативные токены, возможно jwt, и уже их костылями прибивать ко встроенной CUBA-авторизации
Да, похоже, просто сделать не получится, если только из gRPC не вызывать по REST методы для получения токена, что само по себе извращение.
А почему вы не хотите поднимать gRPC сервер на web модуле, а все обработчики хранить в core? Там порты пересекаются или зависимости не получается разрулить нормально? Я быстро погуглил, есть же решение для Spring Boot а почти все, что работает в Spring, можно прикрутить к CUBA. Это, наверное, будет проще, чем писать свой auth manager.
Мы будем думать как поступить. Приложение уже весьма немаленькое и отрефакторить его просто по щелчку пальцев не выйдет. Да и написание собственного auth manager’а возможно не такая плохая идея, по крайней мере в будущем мы не упрёмся снова в ограничения CUBA. Вы вот порасуждайте глобально, что требуется обычному приложению для выдачи токена? Правильно, это доступ к БД или кэшу, где хранятся данные пользователя: логин, хэш пароля, возраст, адрес прабабушки и т.д. Доступ ко всему этому есть у модуля core, но токен выписать он не может. Парадокс 
Можно сделать сервис в core, который выдаст нужные данные и заинжектить его в web часть, которая уже выпишет токен.
gRPC-код весь располагается в core, так что такой вариант не подойдёт.
Ладненько, мы что-нибудь придумаем. Спасибо!