我們一直在使用自定義@Secure攔截器來保護我們的支持bean方法，以防止方法的僞造調用。使用JSF組件提供的足夠安全性來防止僞造的動作調用？
但最近，它碰到我，如果調用動作的組件未呈現，這些方法無法訪問。這是我的理解，JSF將生成視圖，如果組件不是基於權限進行呈現的（例如EL與isUserInRole），那麼任何僞造的POST與該組件作爲源將不會觸發，因爲組件不會在恢復視圖。它是否正確？
基本上，任何僞造都必須有一個妥協的和當前的JSESSIONID，甚至是ViewState，這取決於它們是否需要相同的視圖。
有人可以確認我的假設是否正確，並且如果可能的話，將我指向規範中的某個位置？
謝謝
好的，我想我已經確認，根據規範，非呈現組件的操作確實無法到達。
說明書陳述的2.2.2節：
應用請求期間Values階段，JSF實現必須 調用processDecodes（）成分 樹中UIViewRoot的方法[P1-端]這通常會引起 樹中的每個組件的processDecodes（）方法遞歸調用，如 UIComponent.processDecodes（）方法的Javadocs所述。
它還指出：
在請求值的解碼，一些組件執行特殊 處理，包括：實現了ActionSource（如 UICommand）組件，其認識到，它們被激活，將排隊一個 ActionEvent。該事件將在應用請求結束時遞送 如果組件的直接屬性爲true，則值階段;如果爲false，則在 結束Invoke應用程序階段。
因此，如果按照processDecodes處理它們，ActionSource組件將只對行動進行排隊。望着的javadoc爲：
執行的請求處理生命週期此組件，該組件的所有兒童的 各個方面的應用請求 值階段所需的組件樹處理，這部分 本身， 如下。
- 如果此UIComponent的呈現屬性爲false，請跳過 處理。
所以第一次檢查必須是該組件是否被渲染，如果沒有，跳過休息。 ActionSource從不排隊，動作也不會被調用。
還要說明一點，但看來ViewState是唯一可靠的預防捷克斯洛伐克聯邦作爲JSF 2.2％的規範的：
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-869
先前實現中顯然太可預見的和沒有包括GET請求。規範現在需要這個。
因此，儘管保護服務器端仍然是一種很好的做法，但它似乎足以控制ActionSource組件的呈現。
JSESSIONID是絕對需要的。但如果用戶登錄，可以很容易地訪問它 - 我正在談論用戶登錄時的情況，但據稱無法訪問特定的方法。
另一部分更棘手。如果狀態存儲在客戶端，則可以僞造。除此之外，還有一些機制可以提供與操作和頁面的直接鏈接 - 就像漂亮或簡單的鏈接。如果方法以任何方式暴露，應該限制它。
我會保護他們，以防止未來不斷監測哪些方法以什麼方式公開 - 想象一下如果您想爲應用程序添加REST或SOA接口。
我同意，我認爲最好是預先保證它爲將來的REST服務使用，並且也瞭解在這種情況下任何僞造請求都需要JSESSIONID。我也不使用客戶國家儲蓄，但承認我沒有想到這一點。我想我正在尋找確認，如果我有一個像「保存」方法的支持bean，我唯一的地方是通過有條件渲染的命令按鈕，是否可以安全地假設它不可到達，除非按鈕是渲染？規範中是否有地方談論這個問題？ – MarkL
順便說一句：我認爲它不足以使用我自己的JSESSIONID來「提升」我的特權的原因是，我將不得不提供一個ViewState ID與恢復的視圖關聯的按鈕，這將不會發生如果我沒有適當的角色。 – MarkL
另一點是如何防止按鈕呈現。如果render屬性爲false，那麼該按鈕仍然存在於樹中，我認爲可以僞造一個調用。另一方面，如果使用c：if，那麼它根本不在樹中，調用失敗。 – Arash
我想我可能已經在這裏找到我的答案，只是不知道它的規範與否： http://stackoverflow.com/questions/6524788/how-to-properly-use-isuserinrolerole – MarkL