ASP.NET: разрешение/архитектура аутентификации
Используя простой Javascript:
// Get all li elements
let list_items = document.querySelectorAll('li');
// Loop through all li items
for (let element of list_items) {
// Check if it has child nodes, etc, add class if it does
if (element.childElementCount > 0 || element.dataset.total > 0) {
element.classList.add('new_messages')
}
}
5 ответов
Я думаю, что необходимо сделать, вот является реализация рядом методов запроса полномочий или в бизнес-объектах или в контроллере. Примеры: CanRead (), CanEdit (), CanDelete ()
Когда страница представляет, она должна запросить бизнес-объект и решить, что пользователи авторизовали возможности, и включите или отключите функциональность на основе этой информации. Бизнес-объект может, в свою очередь, использовать Роли или дополнительные запросы базы данных для определения полномочий активного пользователя.
Я не могу думать о способе декларативно определить эти полномочия централизованно. Они должны быть распределены в реализацию функций. Если Вы хотите, действительно улучшают дизайн, однако, Вы могли бы использовать внедрение зависимости, чтобы вставить authorizers в Ваши бизнес-объекты и таким образом разделить реализации.
Существует некоторый код, который использует эту модель в книге Rocky Lhotka. Новая версия еще не находится в Google.
Членство API, обеспеченный начиная с ASP.NET 2.0, должно хорошо подойти Вашим требованиям. Единственной вещью я боюсь, что она непосредственно не поддерживает, являются иерархические роли. Однако можно легко использовать нормальную безопасность на уровне ролей с другой вручную записанной иерархической ролевой таблицей для достижения необходимых вещей.
Можно продолжать читать, как настроить Членство ASP.NET здесь: http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
Это позволяет Вам папкам группы / страницы и т.д. в Группы / Пользователи. Я думаю, что Вы найдете это достаточным!
hiarchy легко управляют путем расширения сгенерированных баз данных и процедур.
Я думаю, что одна из лучших реализаций, которые, как мне кажется, будут соответствовать вашим требованиям, документирована здесь . Единственная проблема заключается в том, что это подключается к NHibernate, но вы можете использовать его в качестве шаблона для создания собственной реализации разрешений и просто подключаться к своей собственной модели событий, а не к модели NHibernates Interceptors.
Я сам работаю над такой системой. и напишу об этом в блоге, когда я буду доволен им.
Я бы построил отношения пользователь/роль так, чтобы у пользователей было более одной роли. Я вижу отношения 1-1 и начинаю нервничать, потому что знаю, что даже если сейчас мы не видим в этом необходимости, однажды кто-то захочет быть одновременно и пользователем отдела продаж, и пользователем отдела обслуживания клиентов.
В нашей клиентской системе мы используем роли, чтобы наложить на них такие вещи, как "delinquentCustomer". Таким образом, первоначальные разрешения остаются в силе - как только они оплатят свой счет. Стоит рассмотреть этот подход.