Комментарии 20
> Но как быть с тем, что требуемые права на доступ к некоторым объектам приложения могут постоянно меняться
Как часто меняются? Я так понимаю, чаще всего эта задача решается кешированием прав на определенный период. Не проще ли такой подход?
Как часто меняются? Я так понимаю, чаще всего эта задача решается кешированием прав на определенный период. Не проще ли такой подход?
В статье была допущена неточность. Идея заключалась в том, что одним сопоставлением текущего пользователя с запрашиваемым адресом (URI) не обойтись. Например, пользователи могут зайти по одному и тому же адресу сообщества, но при этом настройки сообщества видят только модераторы, а обычные пользователи — нет.
Не очень понял вашу мысль.
Урл — по логике вещей — это всего лишь путь к функции и ее агрументы. Поэтому одного урла мало для безопасного приложения- — надо проверять, есть ли доступ к нему.
Урл — по логике вещей — это всего лишь путь к функции и ее агрументы. Поэтому одного урла мало для безопасного приложения- — надо проверять, есть ли доступ к нему.
Не всегда в адресе содержится полный набор аргументов. Рассмотрим конкретный пример. Допустим, пользователь с id = 1 пытается просмотреть альбом сообщества 10 по адресу:
www.campus.ru/gallery/viewalbum/20
Здесь 20 — это идентификатор альбома. Допустим, модератор сообщества разрешил просматривать альбомы в сообществе 10 только пользователям 2 и 3. Тогда в таблице пермиссий появится запись вида
action = view_album, community = 10, acl = {2, 3}
И для функции view_album аргументом будет являться идентификатор сообщества. В адресе же содержится идентификатор альбома. Ситуация легко разруливается CRMedia.Security:
www.campus.ru/gallery/viewalbum/20
Здесь 20 — это идентификатор альбома. Допустим, модератор сообщества разрешил просматривать альбомы в сообществе 10 только пользователям 2 и 3. Тогда в таблице пермиссий появится запись вида
action = view_album, community = 10, acl = {2, 3}
И для функции view_album аргументом будет являться идентификатор сообщества. В адресе же содержится идентификатор альбома. Ситуация легко разруливается CRMedia.Security:
@Restricted(
action = «view_album»,
params = {
@SecuredProp(name = «community», paramProp = «album.community»)
}
}
Object onActivate(@SecuredParam(«album») Album album) {...}
action = «view_album»,
params = {
@SecuredProp(name = «community», paramProp = «album.community»)
}
}
Object onActivate(@SecuredParam(«album») Album album) {...}
Более того, аргументы функции могут быть вообще не связаны с адресами. Они могут быть получены из внутреннего состояния страницы (из свойств с аннотацией @Persist). Особенно это актуально для AJAX-запросов.
А так, конечно, задача уменьшения нагрузки может решаться кэшированием. Проверка прав производится довольно часто, поэтому необходимо хорошо оптимизировать работу системы, например, создать индексы на таблицу разрешений, установить кэш и т.д.
Будьте добры, подсветите код.
А я правильно понял, что библиотека стала свободно распространяемой? А то из приведенного кода не видно всей мощи данной системы. Да и не понятно тогда к чему такая мега универсальность вообще.
Интересно, буду делать подобное. Но только аннотации с ограничениями применю на методы сервисов, зарегистрированных в IoC. Тем самым будет работать при доступе к данным не через страницы tapestry. Плюс сделаю это на базе Ki (JSecurity).
Как успехи? В связи с чем было принято решение налагать ограничения на методы сервисов, а не на события компонентов?
Спасибо, что упомянули Ki — теперь есть соблазн о переезде со Spring на него :) Особенно порадовала поддержка Ki мгновенных изменений ролей, а это открывает широкие возможности для интеграции с CRMedia.Security.
Спасибо, что упомянули Ki — теперь есть соблазн о переезде со Spring на него :) Особенно порадовала поддержка Ki мгновенных изменений ролей, а это открывает широкие возможности для интеграции с CRMedia.Security.
К этому еще не подошёл, поэтому успехов нет. Сейчас много возни с архитектурой платформы. Применять буду как на методы сервисов, так и на страницы (компонеты, микшены), тем более это делается просто :)
Ki мне понравился возможностью работы в stanalone режиме без контейнера сервлетов. А когда он начал переходить под крышу Apache, то сомнения выбора отпали окончательно. А Spring я решил не использовать, вся платформа будет строится на Tapestry5 IoC. Может я что-то не понимаю, но у меня сделано несколько проектов без Spring, по сути там только интересен DAO и Acegi. Все остальное overhead для большинства веб 2.0 проектов. Замена DAO у меня есть, осталось повозиться с Ki и плотно вкрутить в Tapestry5 :)
Ki мне понравился возможностью работы в stanalone режиме без контейнера сервлетов. А когда он начал переходить под крышу Apache, то сомнения выбора отпали окончательно. А Spring я решил не использовать, вся платформа будет строится на Tapestry5 IoC. Может я что-то не понимаю, но у меня сделано несколько проектов без Spring, по сути там только интересен DAO и Acegi. Все остальное overhead для большинства веб 2.0 проектов. Замена DAO у меня есть, осталось повозиться с Ki и плотно вкрутить в Tapestry5 :)
Блин как все сложно, тяжело и некрасиво делается когда по науке
owner,group,chmod X простейшие битовые операнды = 99% всех потребностей
и отдельной веткой moderator\supermoderator\etc
owner,group,chmod X простейшие битовые операнды = 99% всех потребностей
и отдельной веткой moderator\supermoderator\etc
Да, в 99% случаях это работает. Но только в 99% :) Да и разве не проще будет модератору (как и программисту) не думать о том, к чему относится, например, операция вступления в сообщество в терминах chmod — к чтению или записи?
Программирование на высоких уровнях приближает разработчика к естественному языку.
Программирование на высоких уровнях приближает разработчика к естественному языку.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Система безопасности Campus.ru