авторизация пирамиды - индивидуальные представления

Question

В настоящее время я использую простую процедуру проверки подлинности SQLAlchemy + URL Dispatch (без использования метода авторизации пирамиды), то есть я просто поднимаю HTTPForbidden, когда пользователь не может что-то сделать (эти проверки происходят в разных местах, в том числе при проверке деформации и т. д.).

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

Текущее понимание

1. Каждый вид (я использую @view_config декоратор) может иметь одну строку разрешения. Обычно «читать» и «писать», но может быть любой строкой. Multiple permissions in view_config decorator?
2. Каждый пользователь может иметь множество принципалов (почерпнутые из SQLAlchemy + URL Dispatch tutorial)
3. Связь между принципалом и строка разрешения authorization policy, что означает несколько принципалов может иметь ту же строку разрешения.

Это кажется довольно обтекаемый для the example сообщений в блоге и т.д., где определение __acl__ позволяет спецификации, которые могут получить доступ к определенной странице, и где «каждый может читать, но только эти две роли могут редактировать» имеет смысл.

Узкое

Пункт 1. где каждый вид должен иметь один и только один разрешение строки кажется неоптимальным. link in point 1 является примером, где должна использоваться строка разрешений «readwrite».

В частности, я хотел бы создать политику, в которой пользователям A и B разрешено просматривать определенное представление (список элементов), но пользователь A может редактировать определенные поля на этой странице, в то время как пользователь B может редактировать некоторые другие поля (возможно, перекрывающиеся). Методы, которые могут быть достигнуты в настоящее время: -

1. В моей форме проверки (или запроса.POST) я могу check if a user has permissions.
2. В моей генерации формы (я использую деформу) Я могу запускать те же проверки, чтобы отмечать определенные поля как доступные только для чтения.
3. В моем шаблоне я могу выполнить ту же проверку, чтобы скрыть/показать поля по мере необходимости.
4. Каждый отправляет разные URL-адреса, с тонкими видами, которые определяют конкретную строку разрешений и перенаправляют обратно на исходную страницу для POST (только если авторизация просмотра передана).

Первые 3, кажется довольно неуклюжим, в том, что они именно то, что я делал раньше (только теперь мне нужно использовать has_permission вместо проверки request.user.role или request.user.id вручную).

Четвертый кажется более «правильным» при использовании аутентификации/авторизации пирамиды, но для этой цели требуется целая куча новых URL-адресов, маршрутов и представлений. Существенно большая сложность, которую я не могу просто отключить в security.py, как я надеялся, используя метод авторизации пирамиды.

Резюме

ли я что-то пропустил в плане того, как разрешение может сделать свою жизнь проще, потому что все выше, кажется, добавить накладные расходы и сложность кода по сравнению с моим ручных проверок (которые я хочу, чтобы избавиться от, потому что делает аутентификацию распределенной по всему моему коду, в шаблонах, в представлениях и даже иногда в модели).

Answer 1

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

@view_config(..., permission='view-kittens') 
def view_kitten(request): 
    data = {} 
    kitten = fetch_kitten_from_db(request.matchdict['id']) 
    if request.has_permission('view-kitten-name'): 
     data['name'] = kitten.name 
    if request.has_permission('view-kitten-color'): 
     data['color'] = kitten.color 
    return data 

@view_config(..., permission='edit-kittens') 
def edit_kitten(request): 
    kitten = fetch_kitten_from_db(request.matchdict['id']) 
    if request.has_permission('edit-kitten-name'): 
     kitten.name = request.POST['name'] 
    if request.has_permission('edit-kitten-color'): 
     kitten.color = request.POST['color'] 
    kitten.save() 
    ... 

Другим вариант иметь более детальный набор функций зрения, каждый из которых защищен индивидуального разрешения:

@view_config(..., permission='edit-kitten-name') 
def edit_kitten_name(request): 
    ... 

@view_config(..., permission='edit-kitten-color') 
def edit_kitten_color(request): 
    ... 

, которые, вероятно, не будет играть хорошо с Deform, но было бы хорошо для своего рода AJAX-интерфейса.