Как представить разные домены приложений в ACL? - PullRequest
1 голос
/ 03 февраля 2010

Я работаю над веб-приложением, в котором разные группы пользователей имеют разный доступ к Ресурсы. Пока что ничего особенного, я думаю, но есть предостережение; Приложение разбито на «домены», чтобы каждая из наших клиентских организаций имеет свой контент. Здесь я использую более простую модель, чтобы проиллюстрировать мою проблему.

Каждый домен имеет одинаковые типы ресурсов, но каждый экземпляр ресурса связан только с одним доменом. Вот как это будет выглядеть с одним доменом:

Resources: stories, announcements

Roles:
    guest   // read only access
    root    // unlimited access 
    editor  // like guest, but with r/w access to resource "stories"
    admin   // r/w access to both resources

Я предложил два разных подхода для реализации этого с использованием Zend_Acl, Во-первых, просто используйте разные ACL для разных доменов, скопировав для каждого домена. Второй - использовать только один ACL и добавлять новые роли для каждого домена:

Domains: domain0, domain1, domain2

Roles:
    guest
    root
    editor-domain0
    editor-domain1
    editor-domain2
    admin-domain0
    admin-domain1
    admin-domain2

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

Является ли какой-либо из этих подходов хорошим или есть лучшие способы работы с несколькими доменами?

1 Ответ

0 голосов
/ 03 февраля 2010

Другим решением может быть создание подкласса Zend_Acl, более конкретно, методов 'allow' и 'deny'.

Например

allow($role, $action, $resource, $domain) {
 // parent::allow($role . '-' . $domain, $action, $resource);
}

Это не так просто, но вы поняли.

Я не уверен, что вы имеете в виду под экземплярами ресурсов, но я все равно предложу это: «ресурс-домен», например, разрешить («admin», «действие», «story-domain0»). *

...