x-acl легковесная утилита для организации Access Control List (ACL)

от автора

Приветствую, хабра-сообщество!

У каждого проекта (веб-проекта) возникают вопросы по организации прав доступа. В данной области есть определенные готовые инструменты для различных фреймворков Zend, Symfony, Yii и т. д. Вероятно кто-то с чем-то сталкивался и в целом представляет себе, что это такое. Для тех же кто не сталкивался — советую открыть документацию любого из этих фреймворков и ознакомится. В частности автор поста очень плотно работал с Zend_Acl. Но относительно недавно решил изучить вопрос ACL в области C++

Итак, с чего все началось…

Началось все весьма просто, есть самописный проект с неплохой нагрузкой (по этическим соображениям название его не называется, самописный он по историческим причинам, 200К уников). Проект, как в большинстве случаев «диктует традиция» написан на php. Организация списков доступа в нем, как таковая отсутствует — есть банальные условные операторы в случае какой «роли», что делать. Данные костыльные решения в принципе работают, но крайне не устраивают. Вооружившись поиском и здравым смыслом было принято решение создать не большую, легкую c++ утилиту, которой мне бы и хотелось поделится с сообществом.

Конфигурация прав доступа

Проанализировав детальнее зенд и идеологию списков доступа было понятно, что требования к утилите весьма простые, — она должна получить список прав и в зависимости от ситуации ответить разрешен ли доступ к тому, или другому ресурсу, кроме того, т. к. данный конфигурационный файл могут править системные администраторы — им должно быть легко ориентироваться что к чему. Из этих соображений был сделан выбор в сторону привычного конфигурационного ini файла. Пример:

[guest]
view:news
view:comments

Где [guest] — это роль пользователя, а view:news и view:comments — соответствующие ресурсы. Многие могут заинтересоваться, почему, допустим ресурс называется не comments:view, а наоборот view:comments — ответ прост, если условно поделить ресурсы в соответствии с CRUD бд, вы поймете, что не так много можно придумать вариантов, соответственно просматривая роли визуально сразу можно разделить, кто что смотрит, кто обновляет и т. д. Кроме того в таком формате становится возможным сделать так:

[guest]
view:*

Что в свою очередь означает — гостям разрешено все смотреть.
Просто, не правда ли?

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

[moderator]
edit:*:comments

# или
edit:news:comments
edit:wall:comments

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

Простое разрешение неинтересно, очевидно мы можем и запрещать доступ к отдельным ресурсам:

[user]
view:news:28 = deny

Данным правилом мы запретили пользователю просматривать новость с ID 28
Описывать правила для каждой отдельной роли весьма утомительно, поэтому существует механизм наследования:

[user : guest]

В данном случае роль user, кроме своих правил, будет также содержать в себе правила от роли guest

Дополнительной фишкой на мой взгляд является возможность в конфигурации описать случай, когда пользователь может править свои комментарии. То есть только те, непосредственно которые он создал. Для этого используется символ ^

Например:

[user]
edit:comment:^

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

Как это работает

Как говорилось выше это утилита. Соответственно после её успешной компиляции можно выполнить в консоли:

./x-acl --config x-acl.conf --group guest --resource view:news

Спрашиваем есть ли доступ у гостевого пользователя к ресурсу view:news

./x-acl --config x-acl.conf --group user --resource edit:comment:28 \
--user-id 4 --owner-id 4

Спрашиваем есть ли доступ у роли user к ресурсу edit:comment:28, если кто забыл мы поставили правило edit:comment:^, — в данном случае стоит символ ^ поэтому идет проверка аргументов user-id и owner-id на равенство и если они равны (а они равны в данном примере) — доступ будет разрешен.

Где можно скачать и поиграться

github.com/AlexeyParhomenko/x-acl

Список подозреваемых вопросов 🙂

— Зачем изобретать свой велосипед, если есть готовые инструменты?

Автор знаком с некоторыми. Создать новый инструмент побудило:
1. Сделать acl более гибче под наши нужды;
2. Поднять профит по потреблению памяти, т. к. в данном случае в отличии от php нет создания громоздких Zval структур;
3. Поднять профит в скорости. Пока мы тестируем, но если окажется напряжным парсить конфиг каждый раз, — мы сможем перейти на сокетное решение;

— Планируется ли дальнейшая поддержка и фикс багов?

Естественно.

— Для каких ОС работает?

На наших серверах используется дебиан, как и у автора в виде рабочей среды, поэтому точно скажу, что на дебиане работает отлично. На других *nix дистрибутивах должно работать также стабильно, ибо ниче не родного не используется. Ну разве что, кому религия не позволяет использовать boost и то, он только для парсинга коммандной строки 🙂

Очень приветствуются комментарии, т. к. хотелось бы понять насколько полезным может быть в дальнейшем данный инструмент. Либо, если я плохо искал и уже описанный функционал имеется — отправьте в гугл!

Замеченные ошибки/неточности в тексте или исходном коде буду рад выслушать в личке, либо, возможно, какие-то дальнейшие пожелания.

ссылка на оригинал статьи http://habrahabr.ru/post/155099/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *