Динамическая авторизация на основе пользователей в Pyramid

Я следую рекомендациям по безопасности, найденным в документации Pyramid, а также вики-руководство Добавление авторизации

Теперь мне нужно добавить ограничения для одного пользователя, а не для групп.

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

Для первой задачи у меня в корневом ACL будет вот так:

__acl__ = [ (Allow, Everyone, 'view'),
            (Allow, Authenticated, 'view_profile'),
            (Allow, 'groups:editor', 'edit_comment')
]

а как насчет edit_post?

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


person neurino    schedule 05.07.2011    source источник


Ответы (2)


Возможно, вы делаете это слишком сложным. Во-первых, показывать ссылку на представление edit_post только в том случае, если посетитель является автором сообщения. Это решит 99% проблемы, сделав это представление невидимым для людей, которые не должны его видеть. Для другого 1% — умные пользователи вручную редактируют URL-адрес для прямого доступа к представлению редактирования — добавьте что-то вроде этого:

def edit_post(request):
    ...
    if authenticated_userid(request) != author:
        raise pyramid.httpexceptions.HTTPForbidden("You are not this post's author.")
person Kirk Strauser    schedule 05.07.2011
comment
Я думал, что оставшийся 1% готов все испортить ... в любом случае, поскольку часть аутентификации (например, edit_comment) оформляется представлениями, я хотел, чтобы все работало по-прежнему. По крайней мере, пока это не станет слишком сложным, пока вы смотрите ... +1 на данный момент. - person neurino; 05.07.2011
comment
Что ж, нет ничего плохого в том, чтобы встроить такие ограничения в глобальную политику, а не реализовывать их внутри представлений. Однако иногда взгляды - это правильное место. Я легко могу представить множество более сложных ограничений, основанных на времени суток, нагрузке на сервер, дорогостоящих вычислениях и т. д., где было бы больно пытаться написать всеобъемлющую политику верхнего уровня. - person Kirk Strauser; 05.07.2011
comment
Спасибо, теперь это имеет смысл для меня. - person neurino; 06.07.2011

У вас уже есть «Дерево ресурсов», если вы создали ресурс Root в своем проекте. Вам просто нужно добавить к нему узел для posts, который будет возвращать объект Post с определенным __acl__, который содержит только авторизованный идентификатор пользователя. Затем вы можете использовать маршрут edit_posts для перехода по дереву ресурсов к объекту Post с __acl__ на нем.

Это несложно, и Pyramid сделает это за вас.

Если вы не хотите использовать аргумент permission, вы можете выполнить авторизацию внутри самого представления, как предложил Кирк.

Кроме того, если вам не нравится этот метод добавления __acl__ свойств и обхода для авторизации, вы можете реализовать свой собственный AuthorizationPolicy, чтобы делать то, что вы хотите, с заданным списком участников и разрешением.

Суть системы аутентификации Pyramid в том, что она есть, и это здорово. Пирамида ни в коем случае не требует от вас ее использования, а для представлений, которые ее не используют, работа с ней не влияет на производительность.

person Michael Merickel    schedule 05.07.2011
comment
Спасибо, мне становится понятнее, для моих нужд гораздо уместнее (и проще) мне добавить проверку в самом представлении, а не создавать классы для ресурсов и тд. Это то, чего я пытался избежать, но, как сказал Кирк, в этом нет ничего плохого (теперь я это знаю). - person neurino; 06.07.2011
comment
Мне очень нравится ваш подход, Майкл, и, вероятно, это правильное решение для большинства случаев. В моем собственном проекте есть несколько чрезвычайно сложных бизнес-правил, которые входят в процесс принятия решений, и эти правила различаются для каждого представления. Вероятно, это то, что делает меня готовым и желающим спрыгнуть с глобального поезда конфигурации в пользу обработки некоторых вещей локально. - person Kirk Strauser; 06.07.2011
comment
Кирк, ты прав насчет ограничения скорости и особых соображений. Однако эти требования, как правило, ортогональны необходимости простой проверки принадлежности объекта или высокоуровневого шлюза, позволяющего пользователю в первую очередь что-то делать. Кроме того, многие из этих дополнительных проверок — это то, что многие люди делают в промежуточном программном обеспечении (особенно ограничение скорости), поэтому они будут решены еще до того, как вы доберетесь до вашего приложения. Также не забывайте, что каждый объект может предоставлять свой acl динамически, поэтому он может временно лишить пользователя права собственности на основе некоторых критериев. - person Michael Merickel; 06.07.2011
comment
Мне кажется, что это много дополнительной работы. Это, вероятно, не место, чтобы обсуждать это, но у вас есть ссылка на статью, объясняющую, почему я, возможно, захочу пересмотреть свое решение? Я чрезвычайно открыт для перемен, тем более, что я еще довольно рано приступаю к большому проекту, над которым работаю. - person Kirk Strauser; 07.07.2011