目前我使用一個簡單的SQLAlchemy + URL調度認證設置(不使用金字塔的授權方法),也就是說,當用戶不能做某事時我只提出HTTPForbidden(這些檢查發生在各個地方,包括驗證變形等)。金字塔授權 - 自定義視圖
對於一個新項目,我想嘗試使用金字塔的授權方法,但是我已經在定製視圖方面遇到困難。
目前瞭解
- 每個視圖(我用的是
@view_config
裝飾)可以有一個權限字符串。通常'讀'和'寫',但可以是任何字符串,真的。 Multiple permissions in view_config decorator? - 每個用戶可以具有許多主體(從SQLAlchemy + URL Dispatch tutorial收集)
- 主以及許可串之間的鏈路是authorization policy,這意味着多個主體可具有相同的權限字符串。
這似乎是對博客文章等the example,其中定義__acl__
允許誰可以訪問特定頁面規範相當精簡,並在「每個人都可以讀,但只有這兩個角色都可以編輯」是有道理的。
瓶頸
1點,每一個視圖必須有且只有一個權限字符串似乎次優的。 link in point 1就是一個例子,必須使用'readwrite'權限字符串。
特別是我想創建一個策略,允許用戶A和B查看特定視圖(項目列表),但用戶A可以編輯該頁面中的某些字段,而用戶B可以編輯某些其他領域(可能重疊)。方法可以實現,現在: -
- 在我的表格驗證(或request.POST檢查)我可以check if a user has permissions。
- 在我的表格生成中(我使用變形),我可以運行相同的檢查以將某些字段標記爲只讀。
- 在我的模板中,我可以運行相同的檢查以根據需要隱藏/顯示字段。
- 每個提交都會使用不同的URL,使用瘦視圖指定特定的權限字符串,並重定向回POST的原始頁面(僅當傳遞視圖授權時)。
第3看起來相當笨重,因爲他們正是我在做什麼之前(除了現在我需要使用has_permission
,而不是檢查request.user.role或手動request.user.id)。
在利用金字塔認證/授權方面,第四種似乎更加「正確」,但僅僅爲此需要大量新的URL,路由和視圖。基本上有很多額外的複雜性,我不能像我希望通過使用金字塔的授權方法所做的那樣,在security.py
中脫穎而出。
摘要
我錯過了在授權如何讓我的生活更輕鬆方面的東西,因爲所有的上面似乎增加開銷和代碼相比,我的人工檢查(這是我想複雜驅除掉,因爲這使認證分佈在我的代碼,模板,視圖甚至有時在模型中)。
首先,感謝您的快速回復!你的第一個建議看起來非常像我的觀點1.在手動檢查權限時,第二個建議需要AJAX(我不想爲這個簡單的項目考慮這個問題),而且確實很難實現變形。 –
那麼,從根本上在金字塔層面上,你的問題歸結爲「我有兩個需要不同權限的操作,我有一個視圖函數來處理它們」 - 對此的回答是「在視圖函數內手動檢查權限還是兩個單獨查看功能「。我不明白如何能夠爲視圖函數分配多個權限會對此有所幫助,或者在什麼情況下它甚至會有意義。 – Sergey
Re。手動進行檢查 - 我最近一直沒有使用Deform,但我確信可以編寫一些通用函數來檢查Colander模式的每個字段在出路上的權限(並使該部件爲只讀),並開啓(忽略更改或拋出異常)的方式。 – Sergey