Динамическое назначение ролей путям в symfony2

Question

Динамическое назначение ролей путям в symfony2

1

Я пытаюсь реализовать защиту доступа к определенным URL-адресам, используя существующую систему users/groups/role в приложении Symfony2. Я пытаюсь решить, как лучше интегрировать его в Symfony access_control (или, возможно, даже использовать его и управлять доступом вручную).

Проблема в том, что у меня есть url (скажем,/пример), который сейчас доступен любому в группе ADMIN. Эти группы затем имеют более мелкие граненые роли, назначенные каждому. Так, например, группа ADMIN может иметь роли EXAMPLE_GET, EXAMPLE_POST и т.д. Но для других групп может быть только EXAMPLE_GET, поэтому мне нужно взять объект User, захватить связанные группы, получить роли, а затем работать, если этот пользователь может получить доступ к URL-адресу с помощью метода http, который они пытаются использовать.

Первоначально я хотел просто добавить имена групп в качестве ролей (в контексте ролей безопасности Symfony), а затем использовать getRoles() в объекте пользователя, чтобы проверить, имеет ли этот человек доступ к правильной группе для доступа к ней. Тем не менее, оказывается, что список групп, которые у меня есть, не является конечным, и многое другое может быть создано в любой момент, поэтому мне нужно избегать жесткого кодирования групп, если это возможно.

Может ли кто-нибудь предложить лучший подход к этому? Или указать мне в сторону любой документации о том, как достичь этого или чего-то подобного? Ключевым моментом является то, что я не могу жестко кодировать определенные группы безопасности как роли в security.yml, потому что люди должны иметь возможность создавать больше групп без необходимости вручную добавлять новое имя группы в список access_control.

chrismou 06 нояб. 2015, в 15:58

Источник

Теги:

php

security

symfony

acl

1 ответ

Ещё вопросы

mblaettermann · Accepted Answer · 2015-11-06T14-39-00.000Z

Это звучит как VoterInterface который лучше всего подходит здесь: http://symfony.com/doc/current/cookbook/security/voters.html

Я бы не стал делать это напрямую с помощью брандмауэров (подход на основе пути)

Только требуется, чтобы общий пользователь регистрировался, защищая ваши ресурсы от IS_AUTHENTICATED_FULLY, предоставляя брандмауэры в security.yml. Это заблокирует любого пользователя, не зарегистрированного в системе.

Реализация избирателя проверяет все разрешения, а затем возвращает грант или нет.

В вашем методе контроллера просто проверьте необходимый грант следующим образом:

public function showAction($id)
    {
        // get a Post instance
        $post = ...;

        // keep in mind that this will call all registered security voters
        $this->denyAccessUnlessGranted('view', $post, 'Unauthorized access!');

        return new Response('<h1>'.$post->getName().'</h1>');
    }

Спасибо - похоже, маршрут для избирателей - лучший вариант. ACL был слишком излишним для того, что было нужно, и перенести его на поддержку миллионов существующих объектов было бы логистическим кошмаром