Комментарии 9
Dependency Injection — нет, не слышали? А принцип единственной ответственности? А то, что представление должно содержать минимум логики (и поэтому все проверки выносятся в контроллер и фильтры)? Про магические строки я и вовсе не упоминаю.
Ну и да, отдельно хочется услышать, чем вам не угодил стандартный механизм авторизации в MVC.
Ну и да, отдельно хочется услышать, чем вам не угодил стандартный механизм авторизации в MVC.
Ну и да, отдельно хочется услышать, чем вам не угодил стандартный механизм авторизации в MVC.
Механизм авторизации предоставляемый в MVC меня полностью устраивает. Но очень часто возникают ситуации, когда на уже готовой странице заказчик требует разместить/скрыть ссылку, которая должна отображаться только руководителям отделов. Через 2 дня, посовещавшись, заказчик еще требует разместить пару ссылок, но уже для руководителей высшего звена. А это тянет за собой очень много неприятностей. Делать новую страницу только для руководителей, где отличие только в наличии 1-2 ссылок, тоже не вариант. Чем больше сущностей, тем сложнее поддержка всего проекта в целом.
Прошу прощения, может я не дошел до темных недр стандартного механизма, но даже в предлагаемых NuGet'ом системах я не видел, чтобы была возможность раздавать права на доступ до уровня элемента на странице.
Я не говорил, что мой вариант претендует на гениальность и уж точно не является единственно правильным решением. Но я поделился своим опытом выхода из ситуации, когда заказчик меняет задачу на ходу и не один раз за неделю.
Приведенный код откровенно не рабочий и уж тем более речь не идет о нормализации. Но общая идея проиллюстрирована.
Сейчас модуль работает в десятке проектов и был написан с применением всех правил хорошего тона. И будьте уверены, DI и остальные премудрости современного программирования в нем присутствуют. Но выложить его я не мог, так как внутри много вещей, составляющих коммерческую тайну.
SQL код в классах сущностей убил наповал. Так нельзя делать даже ради примеров. Ну можно конечно, но однозначно не стоит.
Все, что вам нужно, уже реализовано в WIF. Наследуйтесь от ClaimsAuthorizationManager и используйте атрибут [ClaimsPrincipalPermission(SecurityAction.Demand, Operation = "...", Resource = "...")].
— возьми уже Entity Framework. Или BL Toolkit. Или хотя-бы хелперы какие-нибудь напиши на крайняк. Рутинный этот код с SQLCommand в 21-м веке выглядит дико
— грузи все что нужно для прав доступа сразу, желательно в один запрос. Можно грузить один раз на запрос в фильтре и класть в RequestContext, можно класть в сессию. Я ведь правильно понимаю что каждый вызов хелпера у тебя — это обращение к базе?
— не нужно делать SQL-запросы в конструкторе. Вообще размазывать загрузку из базы по классам — плохая идея.
— логируй исключения, прикрути библиотеку для логирования, подцепи какой-нибудь IoC с аспектами и положи логирование в аспекты
— char.Parse(" ") — почему не ' '?
— вешать extension-методы для авторизации на класс String — весьма сомнительное решение
— грузи все что нужно для прав доступа сразу, желательно в один запрос. Можно грузить один раз на запрос в фильтре и класть в RequestContext, можно класть в сессию. Я ведь правильно понимаю что каждый вызов хелпера у тебя — это обращение к базе?
— не нужно делать SQL-запросы в конструкторе. Вообще размазывать загрузку из базы по классам — плохая идея.
— логируй исключения, прикрути библиотеку для логирования, подцепи какой-нибудь IoC с аспектами и положи логирование в аспекты
— char.Parse(" ") — почему не ' '?
— вешать extension-методы для авторизации на класс String — весьма сомнительное решение
Господа, отвечу всем и сразу.
Во-первых, я уже писал, что данные код не является продакшн кодом. Естественно, что в «боевой версии» все сделано красиво, удобно и с применением всех магических техник.
Во-вторых, весь код, работающий с БД реализован с применением паттерна Repository. Обращение к БД идет с помощью LINQ2SQL.
Конечно слышал и применяю на практике. Код, приведенный в статье является прототипом. Возможно, из-за недостатка опыта работы с DI, мне сходу бывает трудно написать готовый код сразу.
Во-первых, я уже писал, что данные код не является продакшн кодом. Естественно, что в «боевой версии» все сделано красиво, удобно и с применением всех магических техник.
Во-вторых, весь код, работающий с БД реализован с применением паттерна Repository. Обращение к БД идет с помощью LINQ2SQL.
Dependency Injection — нет, не слышали?
Конечно слышал и применяю на практике. Код, приведенный в статье является прототипом. Возможно, из-за недостатка опыта работы с DI, мне сходу бывает трудно написать готовый код сразу.
Разместить/скрыть ссылку — хелпером в зависимости от роли или через sitemap, тоже самое «Элементы на страницах» — partial или ActionResult. Да, и из одной Html.LinkAction() тоже, в том числе. с отделением логики от представлений в контроллер.
Про свою базу пользователей при готовом AD — я, пожалуй, промолчу. Про int в качестве userid, если в AD есть нормальный GUID для сущности пользователя — тоже. Про использование групп из AD, должностей, отделов и возможность использовать вагон готовых и кастомных полей — видимо, упоминать и не стоит.
Про правила хорошего тона — на вкус и цвет, как говорится, поэтому спорить не буду.
Про свою базу пользователей при готовом AD — я, пожалуй, промолчу. Про int в качестве userid, если в AD есть нормальный GUID для сущности пользователя — тоже. Про использование групп из AD, должностей, отделов и возможность использовать вагон готовых и кастомных полей — видимо, упоминать и не стоит.
Про правила хорошего тона — на вкус и цвет, как говорится, поэтому спорить не буду.
А как с производительностью? :)
Реализовывал подобную систему раздачи прав — сразу сделал загрузку всех правил в синглтон, и периодическое обновление кэша (что бы базу пореже дёргать).
По названиям, рекомендую в коде использовать английские имена наподобие «ServiceDesk.canSetConsider», «ServiceDesk.canTakeProblem» а в админке отображать имя и русский description — так удобнее искать, делая разные сортировки, группировки и фильтры.
Реализовывал подобную систему раздачи прав — сразу сделал загрузку всех правил в синглтон, и периодическое обновление кэша (что бы базу пореже дёргать).
По названиям, рекомендую в коде использовать английские имена наподобие «ServiceDesk.canSetConsider», «ServiceDesk.canTakeProblem» а в админке отображать имя и русский description — так удобнее искать, делая разные сортировки, группировки и фильтры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разделяй и властвуй. Или система разделения прав для ASP MVC