В настоящее время у нас есть сайт, где почти все страницы попадают в некоторый класс страниц, который является подклассом System.Web.UI.Page. Обычно подклассы управляют стилем - верхними и нижними колонтитулами и т. Д. - тем вещами, которые отображаются на том классе страниц, который мы хотим для всех классов.
Для одного конкретного класса мы проверяем некоторые переменные сеанса, чтобы увидеть, есть ли у пользователя доступ к этой конкретной странице. Если нет, их перенаправляют и говорят, что у них нет доступа.
С тех пор я реализовал пользовательский поставщик ролей и сейчас обновляю все мои файлы web.config с до.
Возник вопрос: почему бы не реализовать ограничения на основе страниц в классе страниц вместо реализации методологии поставщика ролей.
Честно говоря, когда я впервые рассмотрел эту тему, мне показалось, что произошло столкновение между тем, чтобы классы страниц выполняли авторизацию. Однако мне трудно найти причины, по которым авторизация на основе класса страниц была бы плохой идеей прямо сейчас.
Если вы в состоянии понять, о чем я говорю, где мы устанавливаем информацию о доступе (авторизации) в процессе входа в систему, а затем используем эту (основанную на сеансе) информацию, чтобы "авторизовать" пользователя для доступа к странице на основе Класс страниц по сравнению с использованием встроенной методологии поставщика ролей ASP .NET, я был бы признателен за ваши мысли по этому вопросу. Особенно, если у вас есть опыт в этой области.
Спасибо.