Ролевое управление.
Ролевое управление.
По терминологии в теме вроде все ясно - пользователь, группы, ресурсы, права.
Можно даже приспособить что-то системное для управления - Активе Директори, ЛДАП, АЦЛ -
или даже рулить всем руками.
Но руками - не интересно, хочется нормальным внятным автоматом с легкой правкой при проблемах
и, самое основное, работающее быстро именно для задачи и адаптируемое под меняющиеся
требования.
Задачка выглядит так (возможно что-то упускаю).
Работает сервис. Веб-сервис, если точнее.
Есть куча пользователей. Ну скажем порядка 100.000, т.е. система нагруженная.
Пользователи загружают и система исполняет некоторый код. Вопрос безопасности загружаемого кода пока опускается.
Количество загружаемого кода - много. Можно считать под 100.000 единиц.
Юзвери могут быть следующие:
- админ, только управление пользователями
- владелец, тот кто загрузил ресурс
- член группы, кто-то с правами на пользование
Загружаемый код делится на 3 категории:
- общий, доступный всем юсерам
- групповой, доступный членам определенной группы и, рекурсивно, включенных групп
- частный, доступный только загрузившему пользователю.
Права на выполнение операций с кодом, насколько Я понимаю ситуацию, будут нужны следующие. На:
- создание, вообще создать что-то в группе
- изменение, что-то изменить в имеющемся в группе
- удаление
- использование
Отдельная процедура - передача прав на код между группами пользователей.
Что-то типа: передать можно только в одну сторону или передать можно только право использования.
Тут думать надо.
Еще где-то с боку лежит версионность кода.
Допустим сделали какой-то специфический чекбох версии 1.0.0.1, потом его 20 раз существенно
модифицировали, дойдя до версии 1.0.20.1. При этом версии 7, 12 и 15 - несовместимы с 1.0.0.1
(совместимость остальных пока опускаем).
Надо как-то управлять доступом к версиям.
Я не тестировал виндовую версию, но по ощущениям она начнет тормозить уже при 2-3 тыс юзеров
и 3-4 тыс управляемых единиц на усера. Не спасет даже отдельный контроллер домена.
Вопросик такой - кто-нибудь видел компактную, независимую от оси, достаточно гибкую систему
управления доступом к ресурсам?
Вопрос второй - какой структурой надо описать отношение между кодом, юсерами, группами и версиями
чтобы время верификации доступа было минимальным. Надо понимать, что приведенные списки
явно неполные и будут модифицироваться.
Ролевое управление.
где ты такие названия находишь? Не думаю, что найдешь что то под твои требования. Но готовое глянуть можно.
https://github.com/Epstone/Simple-MVC-User-Management
https://www.codeproject.com/Articles/23431/AccountPlus
https://archive.codeplex.com/?p=mywsat
https://archive.codeplex.com/?p=aspnetmemberman
https://stackoverflow.com/questions/456921/is-there-a-asp-...
Посмотрел что было по линкам.
Хммм... Что-то есть. Но уж очень примитивно-слабенько. Типа студенческих поделок.
Думаю, что надо копать две вещи:
System.Web.Providers
Microsoft.AspNet.Providers
Насколько хорошо оно будет - не знаю.
Копать там, правда, много...
Но уж очень примитивно-слабенько
Здесь есть одно интересное высказывание, типа так - нефиг палить из пушки по воробьям.
Обычно прогой пользуются небольшое количество пользователей и им нужно просто ограничить заход в различные части проги / не показывать какие то данные.
По крайней мере, других требований мне еще не попадалось.
Обычно
-----
Хи-хи... ну ты же знаешь - у меня редко возникают "обычные" вопросы...
других требований мне еще не попадалось.
-----
Ну вот тебе другое требование:
В папке лежит куча ДЛЛок, нужно расписать кому и что можно с ними делать.
Когда сообразишь как делать для ДЛЛок - добавь еще тоже самое для классов в них...
Сторонний вопрос.
Есть большая ДЛЛка с набором классов. Ну скажем 100 штук.
Загрузка будет производится в ручную.
Из всего набора классов в ДЛЛке нужно инстанцировать 3-5 классов.
Ну и еще 3-5 тыс штук таких ДЛЛок. Перекрытие по доступной памяти - многократное.
Ворпрос - Как не упасть в своп?
у меня редко возникают "обычные" вопросы...
ну так сразу и сказал что быстрее будет самому сделать, что то подобное тяжело будет найти.
В папке лежит куча ДЛЛок, нужно расписать кому и что можно с ними делать.
Вообще то обычный пользователь нифига про ДЛЛ-ки не знает, как и про классы в них. Чёт ты еще пропустил...
Загрузка будет производится в ручную.
Это как? ищем ДЛЛ-ку, ищем класс?
В кино покупаешь большой пакет попкорна - тута большой пакет памяти 
что то подобное тяжело будет найти.
-----
Потому и спрашивается коллективный разум - может кто-то что-то похожее где-то видел.
А стандартная задача... ну чего ее думать - https://msdn.microsoft.com/en-us/library/879kf95c.aspx - все расписано.
обычный пользователь
-----
Ну и Чо?
Ну не совсем обычные пользователи - пользователи пишущие шаблоны Т4.
Так что что там такое - они в курсе.
Мне же надо чтобы они не получали возможность использовать шаблоны на которые у них нет прав.
Ну типа чекбоха - есть права на 1.0.20.1 - использует у себя, на 1.0.0.1-1.0.20.0 - нету - уведомляется
что нету прав и к кому обращаться за ними. Указал без версии - используется максимальная из
доступных. Не нравится эта - указывает какую и добивается прав на пользование.
Как то так.
тута
большой пакет памяти
-----
Нее, не фига - можно компилять в модули и грузить отдельные модули или классы из модулей.
Я это уже делал, примеры где-то лежат. Это вне возможностей Студии, но сие меня не беспокоит.
Проблема в том, что вроде как не получается поместить модули в сабфолдер, а без этого
все будет в одной папке и на 4-5.000 файликов винда начнет загибаться. А мне требуется
много больше - 2-3.000.000 файликов...
Ну разве что это делать "автоматом", но тогда и права не нужны вроде
-----
Делать, разумеется, именно "автоматом", а права - права нужны - не вижу как иначе рулить доступом.
Ну и разумеется, критичные случаи, не вписывающиеся в автомат, разруливать руками.
Делать, разумеется, именно "автоматом", а права - права нужны
Тут чисто логически выходит. Если генерация прав будет происходит автоматом, а после будет происходит что то еще, так можно сразу делать что то еще автоматом.
Для совмещения с ручным вводом будет видимо иначе.