Я являюсь частью команды, создающей веб-приложение с использованием PHP и MySQL. В приложении будет несколько пользователей с разными ролями. Приложение также будет использоваться географически распределенным образом. Соответственно, нам необходимо создать систему контроля доступа, работающую на следующих двух уровнях:
Мне нужна помощь в разработке системы, которая может обрабатывать оба этих типа контроля доступа. Пункт № 1 кажется достаточно простым. Однако я совершенно не понимаю, как выполнить пункт 2 без жесткого кодирования информации в запросах SQL.
Любая помощь будет оценена по достоинству.
заранее спасибо
Винаяк






Мне кажется, что вам нужно следующее: (я буду использовать пример страны / штата / города)
Для городского пользователя, очевидно, искать и отображать только те записи, которые относятся к городу, который соответствует их идентификатору. Однако для уровня штата или страны найдите все записи, относящиеся к каждому городу, идентификатор которого соответствует этой нации (или штату, или какому-либо другому).
Итак, в основном каждая подгруппа зависит от группы над ней, и хотя я не могу правильно вспомнить, я считаю, что вы можете использовать подзапросы, чтобы проделать трюк оттуда.
@ vinayak.myopenid.com, вам все равно придется использовать другой запрос, если вы позволите серверу SQL знать, какой у вас уровень доступа. Похоже, что разрешения будут обрабатываться путем привязки выражений в предложении WHERE к AND. Звучит довольно просто.
Если вы не знаете, как это сделать, я бы использовал PHP-фреймворк, например Zend Framework, CakePHP или Symfony. Они сделали за вас всю тяжелую работу и уже имеют какую-то схему контроля доступа.
Несколько месяцев назад я был в похожей ситуации. Я обнаружил, что такие инструменты, как Zend_ACL, отлично работают, если вы просто проверяете уровень доступа к одному элементу (или достаточно небольшому их количеству). Он не работает, когда вам нужно получить огромный список элементов, к которым пользователю разрешен доступ. Я разработал собственное решение этой проблемы, используя шаблон Бизнес-делегат. BD предоставляет бизнес-логику, которую можно применять в конкретном контексте. В этом сценарии была доставлена логика SQL, которая использовалась в качестве условия фильтрации в подзапросе. См. Следующие схемы:

(source: epsi.pl)
И диаграмма последовательности, показывающая порядок звонков:

(source: epsi.pl)
Я писал об этом решении, к сожалению, все это на польском языке, но вы можете найти фрагменты кода и диаграммы под рукой. Что я могу сказать, реализация - это не кусок пирога, но с точки зрения производительности это чемпион по сравнению с итеративной проверкой доступа для каждого элемента в списке. Более того, указанная выше инфраструктура обрабатывает не только один тип элементов в списке. Он может использоваться при доступе к различным спискам, будь то список городов, стран, продуктов или документов, если элементы в списке реализуют интерфейс IAuthorizable.
Привет, я знаю, что это старый ответ, но мне просто нужно пояснить Диаграмма классов UML, что означают разные типы стрелок? (Сплошные, пунктирные и серые)
@Triztian - сплошные со стрелками - это вызовы методов, пунктирные вертикальные линии представляют собой линии жизни, а пунктирные горизонтальные линии часто представляют собой возврат.
У меня есть аналогичное решение для сборки, и до сих пор я решил использовать спецификации и роли, поэтому фактически к одной роли были бы прикреплены некоторые спецификации привилегий. Если все они удовлетворены, разрешение предоставляется, в противном случае - доступ к ресурсу по умолчанию.
Я искал кого-то, кто уже реализовал решение, но, похоже, никто этого не сделал. Будем надеяться, что не удастся :)
Привет, но это означает, что поисковые запросы должны быть написаны по-разному для каждого уровня пользователя. Моя проблема заключается в том, чтобы найти способ заставить один и тот же запрос возвращать разный набор результатов в зависимости от уровня пользователя.