#c# #asp.net-mvc #authentication #asp.net-identity #claims-based-identity
#c# #asp.net-mvc #аутентификация #asp.net-идентификатор #идентификация на основе утверждений
Вопрос:
На данный момент я работаю с ASP.NET MVC 5 и новая платформа Identity 2 для аутентификации и авторизации. На основе этих принципов я реализовал пользовательскую систему на основе утверждений, которая может проверять, разрешено ли действие пользователя, передавая область и действие (например, область — резервирование, а действие — создание).
Теперь у меня есть требование расширить систему для ее использования в многопользовательском приложении, которое различает арендаторов по вспомогательному пути url. (например https://www.mydomain.com/tenant1/{controller}/{action} .
Платформа идентификации imho не может устанавливать файлы cookie на основе определенного URL-адреса. В каждом месте, где я пытался подключиться и установить путь к файлу cookie, не удалось.
Второй вариант использования, который у меня есть, — это предоставление пользователю временного доступа к набору действий без необходимости последующего выхода из системы. Это также должно работать, если файлы cookie отключены.
Я решил переписать систему аутентификации с нуля, чтобы удовлетворить свои потребности. Каков наилучший способ реализовать временный вход в систему без использования файлов cookie. История: Пользователь хочет сделать резервацию. Поэтому он должен быть аутентифицирован для перехода через мастер (2 или 3 асинхронных запроса к серверу). После завершения работы мастера пользователь должен выйти из системы без какого-либо взаимодействия. Созданные токены должны быть признаны недействительными (используются для режима киоска).
Какие принципы и рекомендации существуют для этого сценария? И опыт работы с подобным вариантом использования?
Комментарии:
1. Единственный способ, которым вы можете это сделать, — использовать что-то в URL, потому что MVC не имеет состояния. Ну, вы, вероятно, могли бы сделать некоторые хакерские вещи, которые будут плохо работать с сессией, но я бы не стал.
2. Что касается идентификации с многопользовательским приложением, то я сделал это следующим образом: ввел требование для клиента, а затем добавил новый атрибут, унаследованный от атрибута AuthorizeAttribute, и, в дополнение к базовому утверждению, проверил базу данных, чтобы убедиться, что файл cookie для входа был для текущего клиента.
3. Я думаю, вы, вероятно, решили эту проблему в какой-то момент между годом назад и сейчас.
Ответ №1:
Посмотрите на проект MembershipReboot. Он поддерживает многопользовательский режим из коробки. MembershipReboot
Написание собственной платформы аутентификации — это последнее, что вам следует делать, если только это не ваш основной бизнес.