Индексация прав в многопользовательских сервисах.

[quark]

Спасибо, познавательно...

[ElenaHell]

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

[NukerF]

Ничего нового, но написано очень неплохо (доходчиво). Думаю статья будет очень полезна начинающим, потому и проголосовал за неё.

[Slach]

ну собственно, если использовать ПОЛЬЗОВАТЕЛЬСКИЕ ГРУППЫ (с виртуальной группой everyone и пользователем anonymous)
права раздавать не на каждый объект а на "группу объектов" или просто на "действие"
и кроме того, при первой авторизации формировать массив UserSecurityContext с заданным TTL (кеширование прав доступа), то при повторном обращении можно довольно сильно экономить

[cloud]

Да, конечно, все это как правило и делается.
Просто основной целью было получить выборку объектов с проверкой прав доступа на уровне выборки из базы.
Если надо вывести, например, постранично френдленту, то получается что надо выбрать n объектов, проверить права на чтение, выкинуть запрещенные и довыбрать еще, при этом постраничный вывод становиться очень нетривиальным так как мы не можем получить количество записей, а ссылки вида ←→ вычисляются динамически.

[Slach]

для этого люди формируют ID записей френдленты в мемкешеде до глубины скажем 500... а потом уже разбивают строго по датам как это делает ЖЖ например -)

[cloud]

Просто на самом деле, кроме френдленты, может быть еще куча выборок (по тегу например) и держать про запас в memcached'е еще десяток страниц на каждую IMHO несколько не экономно.
Хотя все зависит от ситуации.

[Slach]

сериализованные массивый с gzip сжатием в memcached (он умеет хранить "gziped chunks")

[Covex]

Притворюсь, что мы с тобой этого не обсуждали и всё равно тут напишу:

В запросе

SELECT `records`.`id` , `records`.`name` FROM `records` , `user_references` WHERE `records`.`public` =0 AND `records`.`us_id` = `user_references`.`us_id` AND `records`.`access` & `user_references`.`mask` AND `user_references`.`cor_id` =$us_id UNION SELECT `records`.`id` , `records`.`name` FROM `records` WHERE `public` =1

Нет ни дополнительного условия WHERE, ни ORDER BY, ни LIMIT. Если их добавить к запросу, то имхо, для обработки UNION будет использоваться filesort (а это не есть гуд)

[cloud]

Я так понимаю тебе UNION не нравиться? Хорошо делаем ход конем:
1. выделяем первые первые три бита маски под виртуальные группы: все, зарегистрированные, администрация
2. определяем нулевого (id=0) пользователя с отношениями для всех зарегистрированных пользователей (куча фейковых записей- бяка). Т.е.:
user_id ref_id mask
0 * 110...
Если запись "публичная" или "только для зарег" или "только администрация" то access соотв. буду 1,2 или 4, а us_id в records 0 (т.е. поле работает только для связи, идентификатор "владельца" будет дублироваться в другом поля.
Получаем выборку без UNION.
P.S. я не тестировал.

[Set0r]

Я уже как года 3 назад глядя на битовые маски прав в файловых системах стал ими пользоваться и для разграничения доступа в своих проектах, но к сожалению, иногда для выборки нужно было делать сложные операции, когда один бит должен быть установлен, а другой - не должен и т.д. Но это скорее всего были случаи, когда использование битовых масок было не совсем уместным. А в целом - очень удобная штука.

[cloud]

XOR?