@CallerSensitive

CallerSensitive學習

代碼位置（Reflection類）

public class Reflection {

@CallerSensitive
public static native Class<?> getCallerClass();

權限

1. Reflection.getCallerClass()此方法的調用者必須有權限
   1. 由bootstrap class loader(啓動類加載器)加載的類可以調用
   2. 由extension class loader(擴展類加載器)加載的類可以調用
   3. 用戶路徑的類加載都是由 application class loader（應用程序類加載器）進行加載的，換句話說就是用戶自定義的 類無法調用此方法。

作用

1. 方法A要使用Reflection.getCallerClass()方法, 方法A必須用@CallerSensitive進行註解
2. 可以獲得調用者class類型
3. 大多數caller-sensitive方法某種程度上是作爲調用者的代理。當通過反射調用時，這些方法必須經過特殊處理以確保getCallerClass返回的是實際調用者的class類型，而不是反射機制本身的某些類。

驗證

有驗證的朋友留言給我

擴展

另外，據JVM註解@CallSensitive文章，有一個類似的解釋：

這個註解是爲了堵住漏洞用的。曾經有黑客通過構造雙重反射來提升權限，原理是當時反射只檢查固定深度的調用者的類，
看它有沒有特權，例如固定看兩層的調用者（getCallerClass(2)）。如果我的類本來沒足夠權限羣訪問某些信息，
那我就可以通過雙重反射去達到目的：反射相關的類是有很高權限的，而在 我->反射1->反射2這樣的調用鏈上， 反射2檢查權限時看到的是反射1的類，這就被欺騙了，導致安全漏洞。使用CallerSensitive後，getCallerClass不再用固定深度去尋找actual caller（“我”），而是把所有跟反射相關的接口方法都標註上CallerSensitive，搜索時凡看到該註解都直接跳過，這樣就有效解決了前面舉例的問題。

下面是我的理解：
當”我“->反射1->反射2->反射3->反射4->…反射5->N，當我使用反射獲取N的時候,N檢測反射5是否有@callSentitive，有就跳過，繼續查詢反射4是否有@callSentitive，重複這個循環，直到找到沒有@callSentitive的我。
注意：上面的反射的方法都標有callSentitive註解，只有這樣N才能找到我