Управление правами в социальной сети

Давай сосредоточимся на выполнении задачи. Вопрос кеширования — отдельная песня.

"Solve the business case, before optimizing the solution"

"One of the most common mistakes done even by experienced developers is starting to optimize code without identifying the problem"

© Ilia Alshanetsky (один из разработчиков PHP)

Поехали гонять запросы.

Listing 1. Вывод явно назначенных ролей в читабельном виде. Чисто для контроля.
WHERE (u.is_team=0) AND (c.is_team=1) означает "отношения пользователей к группам"

SELECT u.short_name AS user_name, c.short_name AS cont_name, l.short_name AS role_name
FROM x_relations AS e
INNER JOIN x_contexts AS u ON u.cont_id=e.user_id
INNER JOIN x_contexts AS c ON c.cont_id=e.cont_id
INNER JOIN x_roles AS l ON l.role_id=e.role_id
WHERE (u.is_team=0) AND (c.is_team=1)

результат:

user_name	cont_name	role_name
durov	bobrdobr	admins
mary	bobrdobr	members
ivanov	bobrdobr	members
john	photo-moto	admins
ivanov	photo-moto	members
petrov	photo-moto	members

Listing 2. У нас должна быть роль по-умолчанию. Это visitors (id=1)
Переписываем запрос на LEFT JOIN и ifnull()

SELECT u.short_name AS user_name, c.short_name AS cont_name, l.short_name AS role_name
FROM x_contexts AS u, x_contexts AS c
LEFT JOIN x_relations AS e ON (e.user_id = u.cont_id) AND (e.cont_id = c.cont_id)
INNER JOIN x_roles AS l ON l.role_id = ifnull( e.role_id, 1 ) 
WHERE (u.is_team = 0) AND (c.is_team=1)

результат с непрописанными явно отношениями

user_name	cont_name	role_name
guest	bobrdobr	visitors
durov	bobrdobr	admins
john	bobrdobr	visitors
mary	bobrdobr	members
ivanov	bobrdobr	members
petrov	bobrdobr	visitors
guest	photo-moto	visitors
durov	photo-moto	visitors
john	photo-moto	admins
mary	photo-moto	visitors
ivanov	photo-moto	members
petrov	photo-moto	members

Listing 3. Какова роль пользователя john (id=3) в группе bobrdobr (id=5)
(см. требование 1)

SELECT ifnull(e.role_id, 1)
FROM x_contexts AS c
LEFT JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
WHERE (c.cont_id=5)

Выведет "1" (т.е. группа visitors). Отношение не описано явно, сработало условие ifnull

Listing 4. Входит ли john в группу bobrdobr (как участник (2) или администратор (3))
(см. требование 1)

SELECT 1
FROM x_contexts AS c
JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
WHERE (c.cont_id=5) AND (e.role_id IN(2,3))

вернет пустое множество, т.к. нет, не входит
если протестируем группу photo-moto …WHERE (c.cont_id=6)… то вернет "1"

Listing 5. Какие права есть у пользователя john (id=3) в группе bobrdobr (id=5)
(см. требование 2)

SELECT r.act_id
FROM x_contexts AS c
LEFT JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
INNER JOIN x_rights AS r ON (r.cont_id=c.cont_id) AND (r.role_id=ifnull(e.role_id, 1))
WHERE (c.cont_id=5)

результат

act_id
1
3
5

(вывелись права для роли visitors)

Listing 6. Есть ли у john право на blog-post в группе bobrdobr?
(см. требование 2)

SELECT 1
FROM x_contexts AS c
LEFT JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
INNER JOIN x_rights AS r ON (r.cont_id=c.cont_id) AND (r.role_id=ifnull(e.role_id, 1))
WHERE (c.cont_id=5) AND (r.act_id=2)

вернет пустое множество, т.к. нет у него права.
если протестируем группу photo-moto …WHERE (c.cont_id=6)… то вернет "1"

Listing 7a. В каких контекстах john выступает в роли admins?
(см.требование 3)

SELECT c.cont_id
FROM x_contexts AS c
INNER JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
WHERE e.role_id = 3

выведет 6

Listing 7b. В каких контекстах john выступает в роли X, с учетом неявно назначаемой роли id=1 visitors?
(см.требование 3)

SELECT c.cont_id
FROM x_contexts AS c
LEFT JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
WHERE ifnull(e.role_id, 1) = :X

Listing 8. В каких контекстах john может смотреть фотографии (act_id=3)
(см. требование 4)

SELECT c.cont_id
FROM x_contexts AS c
LEFT JOIN x_relations AS e ON (e.cont_id=c.cont_id) AND (e.user_id=3)
INNER JOIN x_rights AS r ON (r.cont_id=c.cont_id) AND (r.role_id=ifnull(e.role_id, 1))
WHERE r.act_id=3

права мы задавали только для групп, поэтому выведутся две записи "5" и "6"
для r.act_id=4 'photo-post' выведется только "6"


Вобщем основные требования выполяются для придуманной структуры. Все проверки можно выразить в SQL.

Фишка в управлении правами на основе назначаемых ролей + "роль по-умолчанию" + легко расширяемый набор прав на операции.

artoodetoo, модель очень хороша… но вот мен интересует вопрос о производительности… касаемо запросов, ведь это необходимо делать будет несколько раз на одну страницу на одного пользователя…

Я бы завел такое кеширование: массив id всех контекстов, где роль данного пользователя отличается от роли по-умолчанию. Тогда обращаясь к любой странице можно быстро вычислить роль.
А если еще для каждого контекста кешировать полный набор допустимых в нем операций по ролям… тогда выяснится что мы засунули в кеш просто все данные о правах :)

Пока нет замеров на правдоподобно больших данных, рано чего-то оптимизировать, IMHO.

[tt]OOO!!! 1234[/tt]

Теперь о PHP.

Предположим мы фанаты MVC. Контроллер выглядит как класс с методами :) круто-крут-круто!
Наш роутер анализирует URL и извлекает из него "controller/action" типично для популярных фреймворков. Например вызывается
GroupController->index() или
PersonController->newPost()
Логично предположить, что в начале ЛЮБОГО ПУБЛИЧНОГО метода контроллера надо получить инфу о правах пользователя. Воспользуемся наследованием от общего предка и protected методом

class CustomController
{
protected 
	$userId,
	$roleId,
	$contextId,
	$availableActions;

protected function applyContext()
{
	$this->userId = Auth::currentUser();

	$this->contextId	= Router::$contextId;
	$this->roleId			= Context::getRole($this->contextId, $this->userId);
	$this->availableActions	= Context::getRights($this->contextId, $this->roleId);

	if (!in_array(Router::$action, $this->availableActions))
		throw new Exception('Access denied');
}

}

// …

class GroupController extends CustomController
{
public function index()
{
	$this->applyContext();
	// some code
	// …
	Template::render('group-index', $data);
}

public function newPost()
{
	$this->applyContext();
	// some code
	// …
	Template::render('new-post', $data);
}

// …

}

выше я приводил запросы, которые должны использоваться в Context::getRole($contextId, $userId) и Context::getRights($contextId, $roleId)
вот как-то так я это вижу…

Творить методы
GroupController->newPost_a
GroupController->newPost_b
не совсем красиво.

некрасиво так называть методы, они должны говорить о сути действия. других некрасивостей не вижу

Вот не надо дезинформации! Только что сами писали — "придется завести по методу на создание каждого типа постов". Помоему это логично, пользователь в роли "крутой" может a, b и c, а в роли "так себе" только a.

В этой системе одно "право" дает ответ Да/Нет. Но почему бы не использовать 3 правила?

Но если хочется обойтись одним методом для трех разных случаев — делайте, пожалуйста. И в этом одном делайте дополнительные проверки для a, b и c на уровне скрипта. Дело вкуса. Только вы уже не сможете на уровне SQL одним запросом найти список ролей или пользователей, кто может выполнить конкретно "действие a". Помоему ТАК делать некрасиво.

Мой выбор — создавать по одному правилу для каждого действия. В роль можно включить сколько угодно правил.

По модели прав надо:
Вася может постить только типы А и С
Петя - только B
Света - А и В

Уточню не "Вася может". А "Роль крутые мальчиши" может.
А "Плохие мальчиши" может только "B".
То есть ваш т.н. "рейтинг" — это Роль.

Мы присваиваем роли конкретным пользователям. А права раздаем на уровне ролей. Это принципиальный момент! Еще раз:

    $this->contextId    = Router::$contextId; // мы определяем контекст для текущего URL
    $this->roleId         = Context::getRole($this->contextId, $this->userId); // Мы находим в какой роли выступает пользователь в данном контексте
    $this->availableActions = Context::getRights($this->contextId, $this->roleId); // Мы получаем набор прав РОЛИ !!!

Набор прав роли в данном контексте может включать любое сочетание a, b, c и еще черт знает сколько действий.

Здесь — нет. Самоцитата: "для нашей условной социалки можно описать правила попроще, но так, чтобы одним SELECT получить ответ на любой вопрос"

А вот в теме Эксперименты с RBAC я разрешаю "задачи могут иметь подзадачи".