Петр, Просто смотрю пример в яндекс апи, там точно так же выдается API ключ, который может жить хоть 1000 лет. Просто какие могут быть подводные камни при таком подходе, как я выше описал?
Петр, Сейчас сделано так: самописный сервис для выдачи JWT, в нем же регистрация, авторизация по refreshToken'y или паролю, изменение пользователя, управление ролями. Но мне не очень нравится JWT, на сколько будет адекватно сделать свою авторизацию на статичных токенах (которые не надо обновлять), хранить их в Redis, так же этот токен пересылать от сервиса к сервису в заголовке, а на сервисе будет своя схема авторизации, которая будет делать обычный get запрос к сервису авторизации с этим токеном, а он будет отдавать все claims'ы, которые есть у этого токена. Так же туда можно будет добавить и свой "client-id", чтобы понимать какому приложению какой токен относится. На сколько это будет выглядеть адекватно?
Петр, Да никаких. Вопрос в целом про то, что делать с авторизацией, как передавать токен из сервиса в сервис, как быть с ролью доступа к списку пользователей и прочее.
MVV, Так, немного момент упустили, наверно. Пока решили оставить всё как было, но вопрос поднялся снова. В общем, объясню еще раз, от EF мы уходить не собираемся, его возможностей нам с головой хватает. В Application слое у нас была зависимость от только UnitOfWork, то есть, в каком-нибудь handler'e медиатра у нас в конструкторе может быть только 2 зависимости: логгер и сам uow. Таким образом, если я убираю инфраструктурный слой, то остается 3: Host, Domain, Application. В Domain у нас нет сервисов(!!!), весь бизнес лежит в Application, потому что у нас не DDD, доменных сервисов нет и быть не может. Собственно и есть вопрос, нужен ли UoW, когда у нас указывает всё на то, что он не нужен и избыточен, когда можно напрямую работать с EF без лишних абстракций.
Ну, как раз таки к EF привязаться и хотелось. Всё делаем на нем, его возможностей нам с головой хватает. В Application не используется ни DataSet, не DbContext, только IUnitOfWork интерфейс и всё.
Василий Банников, ну вот это уже звучит как аргумент :)
Спасибо! Будем слегка смещать UoF в сторону сервисов, которые реализовать будем в Infrastructure, когда это возможно. Можете оформить как ответ, в целом это решает мою головную боль :D
Роман, А еще можно с апи отдавать время жизни токена и проверять время жизни без запроса на сервер, проверил время жизни - подходит к концу или кончилось - обновил - послал запрос дальше, но уже с новым токеном
Nik Faraday, это полный бред. В запросе может и не быть refresh token'a (в 99.9% запросах его и не будет, потому что в обычных запросах он и не нужен), который нужен для обновления jwt, тот, кто вам такое ТЗ дал - пусть и скажет вам, как это должно выглядеть. Такие вещи лежат на плечах клиента, но никак не сервера.
Nik Faraday, EF всю жизнь делает так, что открывает соединение по каждому чиху, а потом закрывает обратно сразу же. Поэтому проблема явно не в том, что просто открываете и закрываете соединение постоянно.
Nik Faraday, с blazor server в этом плане не работал, он в целом какой-то кривой для этих вещей, на wasm никаких проблем не было положить банально в local storage