Итак, в продолжение этой темы. Допустим, мы выделяем в отдельную

Question

Итак, в продолжение этой темы. Допустим, мы выделяем в отдельную

таблицу базовые (общие) св-ва и получаем сл.данные, чтобы один пользователь мог быть и тем, и тем: UserInfo, CustomerDetails, EmployeeDetails, AdminDetails.
Все ссылки на <~>Details у UserInfo nullable. Теперь вопрос авторизации.

Нужно генерить токены для сессии каждых <~>Details сущностей или один общий для UserInfo? При том, что за раз пользователь может авторизоваться только как кто-то один.

И, стало быть, авторизация должна проходить по разным endpoint'ам, верно? Иначе как еще можно определить, кто конкретно сейчас авторизуется?

И, если мы разделяем это и сессии хотим контролировать руками, то появляется базовая сущность Session с потомками CustomerSession, EmployeeSession и AdminSession.

Как вообще правильнее? Сделать Session с тремя nullable ссылками на разные <~>Details или три разные сессии? По хорошему-то они все равно в одной таблице должны лежать.

Я правильно мыслю?

#it #programming #russian #software

0

31.12.2017

1 ответов

9 просмотров

Aleksander Byczkow · Accepted Answer

Aleksander Byczkow

Авторизация не может происходить по разным endpoint'am по идеи. Потому что админы входят по логину, судя по словам выше, а остальные по телефону и в таком случае бэк сам всё разруливает

0

31.12.2017

214 похожих чатов

Итак, в продолжение этой темы. Допустим, мы выделяем в отдельную

1 ответов

Похожие вопросы