Как кодифицировать и хранить динамические ограничения разрешений?

Question

Я уже изучал эту тему, но пока не нашел изящного решения.

Допустим, у нас есть приложение, в котором клиенты могут забронировать курс с помощью веб-сайта, а административный персонал может также забронировать курсы наот имени клиента с помощью бэкэнд-системы.Я пытаюсь найти способ разрешить администраторам HR кодифицировать ограничения, применяемые к разрешениям, таким как can_make_booking, так как разрешение не просто логическое и не должно быть жестко закодировано в приложении.

ВВ данный момент клиенты могут сделать заказ, если в качестве даты курса будет указана дата, как минимум, со стандартным уведомлением за n дней в будущем, они бронируют не больше, чем количество доступных мест, и платят как минимум причитающуюся сумму (или ноль, если для их аккаунта установлен счет-фактура).Менеджеры могут бронировать, используя бэкэнд-приложение, если дата назначения назначена в любое время после этого.

Я предполагаю что-то подобное.Пусть администраторы отдела кадров добавят ограничения разрешений, например:

role      permission    constraint
--------  ------------  ----------
customer  make_booking  1
customer  make_booking  2
customer  make_booking  3
manager   make_booking  5

Затем таблица ограничений

constraint  property        operator  value                       OR_parent
----------  ------------    --------  --------------------------  ---------
1           $course_date    >=        strtotime("+$notice days")  NULL
2           $places_booked  <=        $places_available           NULL
3           $paid           >=        $total                      NULL
4           $send_invoice   ==        TRUE                        3
5           $course_date    >=        strtotime("now")            NULL

Объединение этих ограничений для роли клиента приведет к созданию чего-то вроде следующего: evalКод ed (ограничение # 4 в паре с # 3 является частью последовательности ИЛИ):

if($course_date >= strtotime("+$notice days") && $places_booked <= $places_available && ($paid >= $total || $send_invoice == TRUE)){
    // make the booking
}

Каждое правило может использоваться независимо на каждом этапе, таком как JavaScript и проверка формы, чтобы дать обратную связь, еслибронирование по какой-то причине не может быть сделано.

Однако, скажем, сотрудники HR хотят изменить правило для клиентов, чтобы им разрешалось бронировать только 3 места одновременно, а сумма $paid должна быть вминимальная сумма $deposit?В идеале я хотел бы позволить им динамически создавать эти php-правила, не предоставляя им доступ к написанному в коде.Свойства и значения могут быть обработаны так, чтобы код eval не был проблемой.Я не хочу жестко кодировать каждую комбинацию каждого правила, поскольку в некоторых случаях не было бы четкого способа заранее угадать логику администратора HR.

Я смотрел на версию Zend_ACL утверждений , но, похоже, они не дают той динамики, которую я ищу.Что было бы хорошим способом реализовать эти динамические ограничения?Есть мысли из других сред?Спасибо!

---

Еще немного понимания проблемы из презентации CUSEC Зеда Шоу, говорящей о том, почему "ACL мертв" - http://vimeo.com/2723800

Answer 1

Ну, это одна из областей, которая все еще вызывает довольно большую дискуссию.Как говорят некоторые [кто?- думаю, что это был Этвуд среди других людей, но ссылка ускользает от меня], приложение, которое может сделать все, уже сделано;он называется C. То, что вы хотите сделать, граничит почти с «слишком обобщенной» областью, хотя я вижу смысл в том, что программисту не нужно каждый раз, когда меняется бизнес-правило.

Если бы мне пришлось реализоватьтакая система, я думаю, я бы попытался разбить ее на домены.Вы уже неплохо справились со вторым столом.Просто нормализуйте это по отдельным доменам, которые используются для составления бизнес-правил.Вы создаете бизнес-правило, которое состоит из 1 или нескольких ограничений ИЛИ-вместе.Каждое ограничение нуждается в свойстве, которое ограничено оператором для термина.Термины могут быть хитрыми, поскольку они могут быть чем угодно, от свойства до функции, до составной функции.Вероятно, проще всего проверить свои бизнес-правила, чтобы увидеть, что вам нужно.Начните, скажем, со свойств, логических и обычных вещей, таких как «СЕЙЧАС».

Таким образом, сама схема будет, например, состоять из rules, которые содержат несколько constraints (очевидное преимущество заключается вВы можете привязать их к любой [группе пользователей / предложениям / временному интервалу / другому домену].Они, в свою очередь, состоят из properties, который будет сравниваться с одним из operators (справочная таблица в основном так, что вы можете вводить пользовательские описательные имена для непрограммистов, но вы можете выбрать для него пользовательские функции внекоторый момент) и, конечно, один из terms.Последняя часть является самой сложной, поэтому вам, вероятно, придется указать ее с идентификатором в term_types, чтобы вы знали, сравниваете ли вы другое свойство или функцию.Вы также можете просто VARCHAR это и создать поле с PHP, что не должно быть слишком сложно, учитывая, что у вас есть все опции в properties и / или functions.

Это оченьоткрытая система (и, возможно, есть более эффективные способы ее решения), поэтому, вероятно, это не стоит делать, если вы не знаете, что вам потребуется высокая степень динамизма в бизнес-правилах.