Настроение философско-лирическое, поэтому вместо того, чтобы работать, потянуло поразмышлять, на сколько правильно реализована система прав в CMS Bitrix и как бы это сделал я.
Для начала о своем мировоззрении на права пользователей в информационных системах. Начиная ощупывать своим, надеюсь, аналитическим отделом мозга любую тематику у меня непроизвольно возникает стремление хорошенько её отсистематизировать и разложить по полочкам (чего так не хватало на лекциях от некоторых преподавателей!).
Начинается этот мучительный процесс с выделения минимального набора независимых сущностей. Какие тут сущности или, говоря иначе, сколько типов данных?
Три типа данных: «объект», «операция над объектом», «право на операцию».
Объектом может быть любой источник информации в системе. Например, в обычной социальной сети это может быть профиль пользователя, фотоальбом пользователя, фотография в фотоальбоме, блог пользователя, блог сообщества (слово «группа» уже занята в другом смысле), комментарии, в конце концов, и т.д. Между объектами могут выстраиваться иерархические связи. Пускай объекты можно разделить на активные, которые могут инициировать взаимодействие с другими объектами, и пассивные, которые ничего подобного не могут, а просто ждут, когда кто-нибудь захочет с ними взаимодействовать.
К активным объектам в простом случае можно отнести только аккаунт пользователя, хотя систему можно построить так, что и сообщество, как отдельный объект будет инициировать взаимодействие с другими объектами, пусть даже и цепочка была начата тем же пользователем.
Например, пользователь, как владелец сообщества, хочет от лица сообщества опубликовать новость. Тогда сообщество может инициировать взаимодействие с объектом «блог новостей», владелец которого «администратор». Пользователя можно назвать как бы физическим лицом, а сообщество как бы юридическим. Привет юристам. Что и как получиться, здесь не суть, но важно понимать, что активным объектом может быть любой объект системы при достаточной извращенности создателя системы.
Но в нашем случае пускай это будет только пользователь, точнее его аккаунт, как информационная единица.
Операции… О… Да… Всмысле, ООП… Да… Любители этой парадигмы уже чувствуют. Это действия, которые можно выполнять над объектом. Разные объекты имеют разный набор операций. Например, фотоальбом можно смотреть, редактировать настройки приватности, добавлять фотографии, комментировать их.
Жили б мы в раю с кущами, на этом все закончилось. Но мы живем на земле с м****ами.
Право, или право на операцию — это данные, которыми могут обладать только активные объекты. Эти данные позволяют совершать операции над объектами.
Но, в отличие от первых двух объектов, «право на операцию» — это вычисляемые, динамические данные. Есть ещё такое понятие для них, как «эффективные права» на объект. В разных системах их вычисляют по-разному. Например, берут твои права, выданные администратором, + объединяют с правами групп, в которых ты состоишь, + твоими правами на объекты выше по иерархии, + правами групп, в которых ты состоишь, на объекты выше по иерархии, + отнимают права, которые владелец данного объекта задал запрещать для тебя и групп, в которых ты состоишь, и вуаля, точнее… фуух. А если права не заданы для какого-то из перечисленных объектов, то для вас приготовлены права по-умолчанию. Переходим к Bitrix. То есть как должно выглядить API для такой системы?
Но в Bitrix куча разрозненных и разнородных API на все случаи жизни от тёти Нюры. Не, по сути они одинаковы, но бритвой Окамы разработчики явно не пользуются. Я понимаю, когда для каждого модуля нужно настраивать права по-умолчанию, когда пользователей нужно распределять по разным группам в админке. Задавать группу по-умолчанию для зарегестрировавшихся пользователей и т.д. Но зачем такой мудренный API?
Вы скажете, чтобы не делать слишком сложной структуру данных. Но даю зуб, каждый из вас придумает оптимальную структуру. Может она и в Bitrix такая, но зачем тогда такой API? Если ещё учесть, что в Bitrix нельзя задавать права для отдельного пользователя, а только для групп, то их замечательно можно кэшировать.
В завершении приведу примеры API:
Не знаю, далёк ли я до предела, но думаю, что и так далее.
Для начала о своем мировоззрении на права пользователей в информационных системах. Начиная ощупывать своим, надеюсь, аналитическим отделом мозга любую тематику у меня непроизвольно возникает стремление хорошенько её отсистематизировать и разложить по полочкам (чего так не хватало на лекциях от некоторых преподавателей!).
Начинается этот мучительный процесс с выделения минимального набора независимых сущностей. Какие тут сущности или, говоря иначе, сколько типов данных?
Три типа данных: «объект», «операция над объектом», «право на операцию».
Объектом может быть любой источник информации в системе. Например, в обычной социальной сети это может быть профиль пользователя, фотоальбом пользователя, фотография в фотоальбоме, блог пользователя, блог сообщества (слово «группа» уже занята в другом смысле), комментарии, в конце концов, и т.д. Между объектами могут выстраиваться иерархические связи. Пускай объекты можно разделить на активные, которые могут инициировать взаимодействие с другими объектами, и пассивные, которые ничего подобного не могут, а просто ждут, когда кто-нибудь захочет с ними взаимодействовать.
К активным объектам в простом случае можно отнести только аккаунт пользователя, хотя систему можно построить так, что и сообщество, как отдельный объект будет инициировать взаимодействие с другими объектами, пусть даже и цепочка была начата тем же пользователем.
Например, пользователь, как владелец сообщества, хочет от лица сообщества опубликовать новость. Тогда сообщество может инициировать взаимодействие с объектом «блог новостей», владелец которого «администратор». Пользователя можно назвать как бы физическим лицом, а сообщество как бы юридическим. Привет юристам. Что и как получиться, здесь не суть, но важно понимать, что активным объектом может быть любой объект системы при достаточной извращенности создателя системы.
Но в нашем случае пускай это будет только пользователь, точнее его аккаунт, как информационная единица.
Операции… О… Да… Всмысле, ООП… Да… Любители этой парадигмы уже чувствуют. Это действия, которые можно выполнять над объектом. Разные объекты имеют разный набор операций. Например, фотоальбом можно смотреть, редактировать настройки приватности, добавлять фотографии, комментировать их.
Жили б мы в раю с кущами, на этом все закончилось. Но мы живем на земле с м****ами.
Право, или право на операцию — это данные, которыми могут обладать только активные объекты. Эти данные позволяют совершать операции над объектами.
Но, в отличие от первых двух объектов, «право на операцию» — это вычисляемые, динамические данные. Есть ещё такое понятие для них, как «эффективные права» на объект. В разных системах их вычисляют по-разному. Например, берут твои права, выданные администратором, + объединяют с правами групп, в которых ты состоишь, + твоими правами на объекты выше по иерархии, + правами групп, в которых ты состоишь, на объекты выше по иерархии, + отнимают права, которые владелец данного объекта задал запрещать для тебя и групп, в которых ты состоишь, и вуаля, точнее… фуух. А если права не заданы для какого-то из перечисленных объектов, то для вас приготовлены права по-умолчанию. Переходим к Bitrix. То есть как должно выглядить API для такой системы?
$perms = GetPerms(active_object_id, passive_object_id, $operation=false);
if(perms[‘super_mega_permission’])
{
echo 'ALL';
}
else if(perms[‘write’])
{
echo 'only write :(';
}
etc
{
} Но в Bitrix куча разрозненных и разнородных API на все случаи жизни от тёти Нюры. Не, по сути они одинаковы, но бритвой Окамы разработчики явно не пользуются. Я понимаю, когда для каждого модуля нужно настраивать права по-умолчанию, когда пользователей нужно распределять по разным группам в админке. Задавать группу по-умолчанию для зарегестрировавшихся пользователей и т.д. Но зачем такой мудренный API?
Вы скажете, чтобы не делать слишком сложной структуру данных. Но даю зуб, каждый из вас придумает оптимальную структуру. Может она и в Bitrix такая, но зачем тогда такой API? Если ещё учесть, что в Bitrix нельзя задавать права для отдельного пользователя, а только для групп, то их замечательно можно кэшировать.
В завершении приведу примеры API:
string CBlog::GetBlogUserCommentPerms( int ID, int userID );
string CBlog::GetBlogUserPostPerms ( int ID, int userID );
string GetBlogUserPostPerms::GetBlogUserCommentPerms( int ID, int userID );
string GetBlogUserPostPerms::GetBlogUserPostPerms ( int ID, int userID );
bool CSocNetUserPerms::CanPerformOperation( int fromUserID, int toUserID, string operation, bool bCurrentUserIsAdmin = false );
array CSocNetUserPerms::InitUserPerms( int currentUserID, int userID, bool bCurrentUserIsAdmin );
mixed CSocNetFeaturesPerms::CanPerformOperation( int userID, char type, mixed id, string feature, string operation, bool bUserIsAdmin = false );
bool CSocNetFeaturesPerms::CurrentUserCanPerformOperation( char type, int id, string feature, string operation );
CForumNew::GetUserPermission (незадокументирована).
Не знаю, далёк ли я до предела, но думаю, что и так далее.
