Хитрый вопрос дизайна класса - PullRequest
0 голосов
/ 23 апреля 2011

Я работаю над реализацией класса для управления разрешениями пользователей на моем сайте.

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

Пока что у меня есть следующее:

  • Я сохранил список разрешений, например, addCustomer, delCustomer и т. Д. Каждое разрешение связано со списком ролей пользователей, которым разрешено выполнять это действие.

  • У меня есть простой класс разрешений. Я использую что-то вроде этого:

    if ($ permissions-> can ('addCustomer')) эхо "Добавить клиента"; еще echo 'Нельзя добавлять клиентов';

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

site.com/messages/read/100

до

site.com/messages/read/101

И прочитайте также сообщение № 101, которое может находиться между другим клиентом и сотрудником. Клиент не должен иметь возможность читать чьи-либо сообщения, кроме него самого.

Аналогично, клиент получил разрешение editCustomer, которое позволяет ему редактировать свой профиль, перейдя по адресу:

site.com/customers/99

(где 99 - его идентификатор клиента)

Но если он пойдет в site.com/customers/100

Он не должен иметь доступа к этой странице.

Как я могу решить эту проблему? В идеале я хотел бы иметь возможность передать идентификатор в класс прав доступа. Например:

if (! $permissions->can('readMsg', $msgId))
   echo 'not allowed';

if (! $permissions->can('editCustomer', $requestedCustomerId))
   echo 'not allowed';

Есть какие-нибудь идеи, как мне пришлось бы реструктурировать структуру моего класса, чтобы разрешить подобные вещи?

Ответы [ 2 ]

1 голос
/ 23 апреля 2011

Я был бы более детализирован в моей таксономии разрешений (например, «readOwnMsgs» против «readAnyMsg»).Это разработало бы ваш код проверки прав доступа (например, site.com/messages/read/### идет примерно так: «продолжить, если canReadAnyMsg или canReadOwnMsg и автор сообщения является текущим пользователем»), предполагая, что эта логика должна бытьинкапсулированные в отдельные классы с разбивкой по типу ресурса или любым другим обстоятельствам, которые могут повлиять на контекстную информацию, необходимую для принятия таких решений.

1 голос
/ 23 апреля 2011

Я хотел бы иметь класс сообщений с функцией canRead(User). Это проверит разрешения пользователя и скажет: «О, я сообщение от менеджера сотруднику. Если пользователь не получатель сообщения, они не могут его прочитать». или просто так: «Я - сообщение от менеджера сотруднику. Пользователь - менеджер, поэтому он может его прочитать».

Я печатаю это по-английски, потому что я сосу php (который, кажется, является языком выбора).

...