Разработка имен разрешений - PullRequest
Новая
       4

Разработка имен разрешений

0 голосов
/ 20 сентября 2011

Я ищу источники информации о разработке имен разрешений для нашего веб-приложения.

Например, если мне нужно разрешение на создание нового сотрудника, его можно назвать create_staff, new_employee, add_worker или любое количество различных имен для одной и той же вещи.

Для этого нового разрешения сотрудника может потребоваться несколько разрешений «родителя» для работы;edit_employee_name, update_date_of_birth и т. Д. В настоящее время, повторяя имена этих «родительских» разрешений, их нельзя отличить от дочерних разрешений.

  1. Можете ли вы порекомендовать стратегию проектированиясогласованные имена в приложении?
  2. Возможно, более важно, существуют ли какие-либо инструменты для управления центральным «списком» имен разрешений, возможно, с помощью групп разрешений или гнезд, чтобы разработчики, дизайнеры баз данных и персонал отдела кадровзнаете, что вызывать, что хранить и что это делает?

Мы кодируем в php и MySQL (и в настоящее время используем phpGACL), но подходы с любого другого языка приветствуются.Спасибо!

1 Ответ

0 голосов
/ 20 сентября 2011

Вы можете найти вдохновение в linux, где права «читать», «написать» и «выполнить» и добавить эти или подобные глаголы к вашим собственным существительным.(Я думаю, что вы на правильном пути.)

Скорее всего, вы ищете термин ACL (список контроля доступа).Zend_Acl - это реализация PHP этого шаблона, которая поддерживает довольно мелкозернистые решения, такие как наследование. Эта статья , надеюсь, станет хорошим руководством по использованию Zend_Acl, даже если вы еще не знакомы с Zend Framework.MySQL прекрасно подходит как хранилище для дизайна Zend_Acl.

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

Ответ на комментарий:

Вы действительно должны поговорить с участниками (оба дизайнера).и пользователи) с ACL, чтобы увидеть, что им нравится.Начальная точка может быть verb_noun(s).Удостоверьтесь, что на каждое правило можно ответить с истинным или ложным, иначе правило не ясно.Убедитесь, что дизайнеры и пользователи знают, что означает каждое существительное и глагол в вашем контексте, включая доменную / бизнес-логику.Также убедитесь, что возможные бизнес-термины не используются, например, если ваша компания использует вымышленные имена, которые могут означать что-то другое в «dev-говорить» - не используйте его.Еще одно правило, которое может помочь: избегайте стоп-слов .

конструкторов и пользователей = разработчиков и тех, кто когда-либо читал название правила:)

...