在純粹的RESTful場景中,客戶端根本不管理ACL。相反,當客戶請求信息時,返回的資源將包括從這些資源到客戶可能遵循的可能鏈接的鏈接。通過這種方式,服務器告訴客戶哪些資源可以使用和不能使用哪種資源(特定於誰請求資源)。
示例:您的JS客戶端爲已購買但尚未發貨的項目檢索JSON有效內容。因爲服務器返回的取消,發貨鏈接關係
{
"name": "Gadget 1",
"price": "16.99",
"status": "ORDERED",
"_links": {
"details": { "href": "/item/a631723d69/details",
"method": "GET"),
"cancel-shipment": { "href": "/item/a631723d69",
"method": "DELETE" }
}
}
,這意味着,在訂單中的項目被允許在目前被取消:客戶端可能會收到的有效載荷,看起來像這樣。但想象中的資源可能是什麼樣子後,它的運輸和請求提出了若干天之後:
{
"name": "Gadget 1",
"price": "16.99",
"status": "SHIPPED",
"_links": {
"details": { "href": "/item/a631723d69/details",
"method": "GET")
}
}
取消裝船鏈接關係將不再從服務器返回的,因爲它不再是一個允許的操作(即在發貨後您不能取消訂單)。
更傳統的訪問控制可以以相同的方式管理(即,不要將取消 - 裝運鏈接發送給未授權的用戶)。假設訂單尚未發貨,您的配偶可以看到您訂購的是什麼,但不允許取消訂單。他們會得到這個回:
{
"name": "Gadget 1",
"price": "16.99",
"status": "ORDERED",
"_links": {
"details": { "href": "/item/a631723d69/details",
"method": "GET")
}
}
因此,在總結,在每一個響應返回的鏈接封裝和代表什麼請求者被授權在系統任何特定的時刻做。
在任何情況下,您都需要檢查服務器上是否有適當的授權請求,因爲您永遠不知道何時可能會有人使用原始URL進行黑客入侵。
啊,這是一個很好的觀點。我沒有想過僅僅根據返回的鏈接來制定客戶策略。事後看起來相當明顯..謝謝! –
@Jonathan W:同樣的道理,你認爲根據授權用戶的權限修改Order對象的實際結構是否有效?例如,如果我的妻子可以看到我已經訂購的東西,但不應該看到我付了多少錢,那麼您認爲返回沒有價格屬性的訂單對象是否有效? – MajorRefactoring
你是什麼意思「訂單對象的實際結構」?您的意思是根據您的身份返回Order資源的不同表示形式嗎?你可以做到這一點,但請記住,這會混淆你有效緩存資源的能力。 (正如我已經指出的那樣,我對這個問題的回答也是如此。) –