мсущкаПочему легаси провайдер ролей? Где написано, что он легаси? По поводу SSO я тебе ответил на вопрос, как реализовать безопасность на нескольких сайтах. Что не так?

Ну смотри, в ASP.NET Identity при SSO мы получаем набор клеймов, утверждений. А ты что имеешь в виду?


мсущка1. Есть статичные роли. То есть такие роли, которые нельзя удалять из базы. На них пляшет бизнес логика.
2. Есть динамичные роли. По сути, это контейнеры для пермиссий.

А зачем прибивать гвоздями к этим ролям? Если у тебя всё равно на выходе пермиссии? Роли - неудаляющиеся из базы, это костыль какой-то. Сам так делал когда-то, но потом понял, что это вафля какая-то, роли они для администратора, инструмент организации. Мне нужны лишь разрешения, можно что-то делать/показывать, или нельзя. Нафига мне роли?

мсущкаУ меня типизация - для статичных ролей. Для динамичных ролей вообще ничего не надо, ибо динамичная роль не несет в себе никакой смысловой нагрузки. Гораздо важнее, какие пермиссии намаплены на такую роль. А пермиссии - точно так же статичны. По них сделаны енумы и жестко зашиты в коде.

Т.е. по твоей схеме, пермиссию нельзя состряпать в админке? Ухх.. эпоха мезозоя )))

Ну типизация на енумах это неплохо конечно. Но в итоге у тя бардак: енумы, проперти, функции IsXXX().

мсущкаИзучи проект, потом приходи на экзаменацию http://codearticles.ru/articles/487

ООоокей )


мсущкаНу потому что часто очень удобно завязывать сразу на роль-константу, а не набор пермиссий. Оперировать в логике такими ролями гораздо удобнее.

Типа "менеджер" или "админ" ? Это халтурщина ))


мсущкаДинамика с ролями и пермиссиями нужна в более серьезных решениях.

Ну и как потом сопровождать это? Или ты бекапишь свой мозг, а одепты накатывают его себе в подкорку?

мсущкаА какой от нее смысл? Программа ничего про неё не знает. Пермиссии - это всегда было жестким хардкодом во всех системах. От шарепоинтов до сапов.

Чессговоря, мы от этого ушли. Т.е. пермиссия это всего лишь разрешить или не разрешать операции + условия, она вычисляется и никакими енумами ты их не задашь. Кроме станадартных операций типа create/modify/delete/view, может быть расширенный набор операций. Например, изменить запись ты не можешь, но можешь перевести статус, или отправить на рецензию... и при этом технически, запись изменяется, поэтому не катит такой подход. Набор пермиссий растёт как грибы после дождя, их количество может перевалить за сотню и даже за тысячу, этим управлять решительно невозможно. Поэтому ушли от этого. Полная динамика, енумы есть, но только для базовых операций и базовых объектов (корневых). В остальном через админку можно настроить всё, добавлять любые разрешения, настраивать их логику, условия и даже длительность. Стандартный подход, который ты описал, катастрофически неудобен, сложен в поддержке и сложно управляем.

мсущкаДа. Почему халтурщина?

Ну потому что схалявить решил :)


мсущкаТак в большинстве случаев пермиссии - жестко зашиты с ISecurityService под роли и как-то всё это админить не надо. Дал роль юзеру, он сразу получил пермиссии. В 99% случаев годный вариант, пермиссии не выносятся куда-то в базу.

Это работает, согласен. Но не гибко, и не расширяемо. Например была себе роль админ. А потом руководство решило ограничить админа и забацать суперадмина, который может только пользователями рулить, но никакими правами в системе не обладает, т.е. не может ничего ни видеть, ни редактировать, только пользователи. В твоём случае надо код переколбасить. В моём, зашёл в админку и сделал свои дела. Ни строчки кода не поменялось.

мсущкаЯ понимаю, но в данном случае не нужна гибкость и расширяемость. Если раз в сто лет потребуется поправить пермиссию, допилю сервис и забуду. Зачем нам пальба из пушки по воробьям?

Просту у тебя ПО по ходу деревянное и полудохлое. У нас в юзервойсах только за неделю 40 открытых заявок. Запросы на новую функциональность сыпятся каждый день. Бредовые конечно отсеиваются, часть попадает в milestone. Это не считая того, что исходит от руководства и что подпихивают бизнес-аналитики.

"Раз в столет" что-то там поправить -- типа стряхнуть вековую пыль с ПО, которое по ходу толком-то и не используется, расчихлить со вздохом исходники и поправить искомое? Если оно так, то да, согласен. Нафиг заморачиваться ))

мсущкаУспешность ПО и заключается в том, чтобы его не трогать. Написал и забыл, дальше его саппортят, а у тебя другие задачи. Вопрос в том, чтобы процессы были правильно поставлены. А новые фичи должны быть экономически обоснованы с соответствующими выгодами.

Какие ещё другие задачи? Пол мыть? Посуду протирать? Чё ты там в офисе делаешь, если у вас разработка -- не бей лежачего, сиди в носу ковыряй, когда там кто-то экономически обоснует какую-нибудь сраную доработку и выгоду подсчитает, а пользователи куй дождутся своей фичи и поуходят нафиг в декреты, да внуков своих насожают с наивной надеждой, что хоть они чего-то там дождутся

мсущкаПока подсчитываются выгоды, решаются другие проекты. Их очень много.

ясно, много проектов с вялотекущим развитием. твой подход вполне катит, я тоже не заморачиваюсь на проектах с коротким циклом ТЗ-решение.

мсущкаЖизнь динамична, что-то срочно, что-то не совсем. По-разному. Есть задача - она решается.

Звучит как "налепить какую-то кривую нашлёпку по требованию"

мсущкаhVosttЗвучит как "налепить какую-то кривую нашлёпку по требованию"
Простота не означает кривизну :)

Простота ≠ серебряная пилюля. Role-Permisson, AuthorizeAttribute и RoleProvider — это весьма примитивный подход для решения не сложного круга задач.

мсущко9Провайдер ролей себя окупил лет на 100 вперед. С ним никаких проблем нету, особенно учитывая факт, что у меня в 99% случаев доменная аутентификация.

Чёт я ни в одном серьёзном проекте не заметил, чтоб он себя окупил. Деревянный обрубок, который постоянно допилилвают все кому не лень. И даже если лень, то приходится. И даже наизобрелати целый набор натфилей, чтоб дотачивать было как-то по-проще. Но обрубком был, обрубком и остаётся. Единственный плюс, провайдер хорош для старта, чтоб не заморачиваться. Но чуть вопросик какой, нааааачинаается сразу... это типа не проблемы провайдера, так нельзя, он для этого не преднозначен, решайте где-нибудь ещё, бла... бла... бла.