Комментарии 12
Вопрос 4. Почему не acl сервер?
Мысль лично мне интересная, тк недавно искал ацл сервер, собственно отсюда и вопрос. Зачем каждый раз поднимать процесс, парсить конфиги и т.д. и т.п. Чем концепция легкого acl демона не подошла?
Мысль лично мне интересная, тк недавно искал ацл сервер, собственно отсюда и вопрос. Зачем каждый раз поднимать процесс, парсить конфиги и т.д. и т.п. Чем концепция легкого acl демона не подошла?
Дельный вопрос. В статье, видимо вы не заметили оговорку:
— но если окажется напряжным парсить конфиг каждый раз, — мы сможем перейти на сокетное решение;
Ничего не стоит перейти на концепцию легкого демона. Тем более, что перед глазами есть исходники и это элементарно сделать имея уже рабочую концепцию.
На текущий момент остановились по соображениям, что можно запускать консольно с разными конфигами, если это проекту необходимо. + потому что у нас она в тестовом режиме, пока. Но думаю, что в ближайшее время вырастим до демона :)
— но если окажется напряжным парсить конфиг каждый раз, — мы сможем перейти на сокетное решение;
Ничего не стоит перейти на концепцию легкого демона. Тем более, что перед глазами есть исходники и это элементарно сделать имея уже рабочую концепцию.
На текущий момент остановились по соображениям, что можно запускать консольно с разными конфигами, если это проекту необходимо. + потому что у нас она в тестовом режиме, пока. Но думаю, что в ближайшее время вырастим до демона :)
Да, не дочитал это предложение до конца ). Если дорастете до шустрого маленького сервера с поддержкой разных источников листов (типа из базы, чтобы как минимум можно было вносить изменения и не перезагружаться после), дайте знать. Алcо, по поводу запуска с разными конфигами, можно добавить например поддержку неймспейсов и спокойно работать с разными листами. Да она у вас уже вроде есть…
Так? :)
[guest]
publicproject:view:* = allow
privateproject:view:* = deny
./x-acl --config x-acl.conf --group guest --resource [PROJECT_ID]:view:news
Так? :)
Да, конечно. Так можно организовать ресурсы, но как-то костыльно вроде выглядит :)
Насчет маленького сервера — я думаю стоит попробовать, но что меня в данном случае смущает — это то, что решение с сервером не всегда равняется шустрости. Я не готов говорить на эту тему без конкретных цифр производительности, но учитывая издержки создания сокетов, контексты переключения оси между потоками не факт, что оно будет намного шустрее, чем обычная консольная отработка. Сейчас вся эта штука при проверки роли по данным valgrind выделяет (alloc) 99 объектов используя при этом ~12кб памяти, что мне кажется вверх «шустримостью», но конечно если файл ролей вырастить до каких-то чудовищных размеров — это шаг к оптимизации. В любом случае, давайте попробуем с демоном и посмотрим, что из этого выйдет.
Насчет маленького сервера — я думаю стоит попробовать, но что меня в данном случае смущает — это то, что решение с сервером не всегда равняется шустрости. Я не готов говорить на эту тему без конкретных цифр производительности, но учитывая издержки создания сокетов, контексты переключения оси между потоками не факт, что оно будет намного шустрее, чем обычная консольная отработка. Сейчас вся эта штука при проверки роли по данным valgrind выделяет (alloc) 99 объектов используя при этом ~12кб памяти, что мне кажется вверх «шустримостью», но конечно если файл ролей вырастить до каких-то чудовищных размеров — это шаг к оптимизации. В любом случае, давайте попробуем с демоном и посмотрим, что из этого выйдет.
А ему необязательно быть многопоточным если он будет очень быстрым. Что важно, это крайне быстрая работа с огромными списками. Так же было бы неплохо и для производительноси и вообще иметь пакетную обработку
а получить список разрешений для пользователя по маске (--resource project:*:news) как-то можно?
А что вы хотите этим сказать?
Вы задаете правила в конфиг файле. Что у вас там разрешено или запрещено. Далее по мере проверки прав в своем приложении вы спрашиваете, а разрешено ли мне --resource project:test:news
При условии, что вы задали правило для указанной роли, например, как project:*:news = allow
Вам соответственно утилита ответить access allow.
Если вопрос был в том, чтобы получить куда-то на клиента список всех *:news — нет, так нельзя. Утилита дает лишь ответ access allow или access denied, ибо она призвана делать проверку прав в соответствии с заданными шаблонами, не более.
Вы задаете правила в конфиг файле. Что у вас там разрешено или запрещено. Далее по мере проверки прав в своем приложении вы спрашиваете, а разрешено ли мне --resource project:test:news
При условии, что вы задали правило для указанной роли, например, как project:*:news = allow
Вам соответственно утилита ответить access allow.
Если вопрос был в том, чтобы получить куда-то на клиента список всех *:news — нет, так нельзя. Утилита дает лишь ответ access allow или access denied, ибо она призвана делать проверку прав в соответствии с заданными шаблонами, не более.
Например: сайт показывает только разрешённые действия для, скажем, комментариев.
Получается, единственный выход — это для каждого комментария, для каждого действия (view/edit/delete) нужно делать вызов. Ну или показывать все возможные действия, а потом радовать пользователя сообщением «Forbidden».
Я все верно понимаю?
Получается, единственный выход — это для каждого комментария, для каждого действия (view/edit/delete) нужно делать вызов. Ну или показывать все возможные действия, а потом радовать пользователя сообщением «Forbidden».
Я все верно понимаю?
Да, верно — нужно для каждого действия спрашивать разрешение. А разрешено ли мне view или edit или delete.
Это базовые построения ACL и мне сложно представить, как можно проектировать иначе. В фреймворках озвученных мною в посте подобные принципы происходят за кулисами методов isAllow, например. Да и в любых системах основанных на списках доступа — вы получаете массив списков, как-то их храните, при запросе разрешения проходите по массиву и если находите соответствие — разрешаете или нет. На конечных, администраторских страницах, если вам нужно показать список доступных действий — вы можете уже предусмотреть вытяжку их напрямую из конфигурационного файла, ибо вы знаете что описали и для чего.
Это базовые построения ACL и мне сложно представить, как можно проектировать иначе. В фреймворках озвученных мною в посте подобные принципы происходят за кулисами методов isAllow, например. Да и в любых системах основанных на списках доступа — вы получаете массив списков, как-то их храните, при запросе разрешения проходите по массиву и если находите соответствие — разрешаете или нет. На конечных, администраторских страницах, если вам нужно показать список доступных действий — вы можете уже предусмотреть вытяжку их напрямую из конфигурационного файла, ибо вы знаете что описали и для чего.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
x-acl легковесная утилита для организации Access Control List (ACL)