@CallerSensitiveCallerSensitive学习

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才能找到我

最后

以上就是大力哈密瓜为你收集整理的@CallerSensitiveCallerSensitive学习的全部内容，希望文章能够帮你解决@CallerSensitiveCallerSensitive学习所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。