shiro的SecurityUtis

接着上一篇来继续分析shiro源码

这篇主要讲解shiro里面的SecurityUtils

首先我们看该类供我们在业务中用的仅有两个get方法,那么这两个get方法获取的subject和sercurityManager怎么来的,我们具体分析

首先我们已经知道每次请求在被拦截后都会走AbstractShiroFilter里的doFilterInternal方法,如果不清楚请先看我的《spring集成shiro登陆流程》的上下篇。

AbstractShiroFilter

其中有这么段代码

//调用DelegatingSubject的execute(Callable<V> callable)方法
subject.execute(new Callable() {   public Object call() throws Exception {     updateSessionLastAccessTime(request, response);     executeChain(request, response, chain);     return null; } });

这里调用了DelegatingSubject的execute(Callable<V> callable)方法

DelegatingSubject

进来看

public <V> V execute(Callable<V> callable) throws ExecutionException {
    //这里创建了一个Callable对象,进去看 Callable
<V> associated = associateWith(callable); try { return associated.call(); } catch (Throwable t) { throw new ExecutionException(t); } }
//继续
public <V> Callable<V> associateWith(Callable<V> callable) {
  //这里将subject对象传递到SubjectCallable
  return new SubjectCallable<V>(this, callable);
}
 

SubjectCallable

 注意看这里创建了一个SubjectThreadState对象

public SubjectCallable(Subject subject, Callable<V> delegate) {
        this(new SubjectThreadState(subject), delegate);
    }

//这个方法主要是将subject对象和securityManager 放在SubjectThreadState上下文
public SubjectThreadState(Subject subject) {
    this.subject = subject;

SecurityManager securityManager = null;
  //从subject中获取securityManager对象,每次请求都会将securityManager对象放到subject上下文, (DefaultSecurityManager#createSubject的ensureSecurityManager)
if ( subject instanceof DelegatingSubject) {
securityManager = ((DelegatingSubject)subject).getSecurityManager();
}
if ( securityManager == null) {
securityManager = ThreadContext.getSecurityManager();
}
this.securityManager = securityManager;
}

 那么到这儿,在SubjectThreadState中就有了subject和securityManager对象

继续看到DelegatingSubject的execute方法

执行associated.call()

我们点进去看  SubjectCallable#call

SubjectCallable

//首先我们注意到doCall方法就是调用了Callable的call方法,也就是异步执行了executeChain(request, response, chain);方法,简单说就是调用验证等流水账然后进入我们的业务代码
//我们调用SecurityUtis.getSubject就是在doCall异步执行里用的
public
V call() throws Exception { try {
        //我们发现执行目标业务之前有个bind方法 threadState.bind();
return doCall(this.callable); } finally {
       //执行完后会清空bind的数据 threadState.restore(); } }
protected V doCall(Callable<V> target) throws Exception {
return target.call();
}

 很有必要再进SubjectThreadState方法看看bind这个方法

SubjectThreadState

public void bind() {
        SecurityManager securityManager = this.securityManager;this.originalResources = ThreadContext.getResources();
    //清空ThreadContext里的数据 ThreadContext.remove();     //将subject和securityManager绑定到ThreadContext ThreadContext.bind(
this.subject); if (securityManager != null) { ThreadContext.bind(securityManager); } }

 走到这儿我们发现把subject和securityManager绑定到ThreadContext

那么这个ThreadContext就很重要了,必须看看

ThreadContext

//定义了个跟线程绑定的ThreadLocal
private
static final ThreadLocal<Map<Object, Object>> resources = new InheritableThreadLocalMap<Map<Object, Object>>();
//将subject和当前线程绑定
public static void bind(Subject subject) { if (subject != null) { put(SUBJECT_KEY, subject); } } //将securityManager和当前线程绑定
public static void bind(SecurityManager securityManager) { if (securityManager != null) { put(SECURITY_MANAGER_KEY, securityManager); } }

那么我们应该再看看SecurityUtils的两个get方法

//从ThreadContext中获取,没有就创建一个并绑定
public
static Subject getSubject() { Subject subject = ThreadContext.getSubject(); if (subject == null) { subject = (new Subject.Builder()).buildSubject(); ThreadContext.bind(subject); } return subject; } //先从ThreadContext中获取,如果没有则从SecurityUtils中获取,如果没有就直接从SubjceUtils中获取(如果是spring项目,那么在spirng的配置文件长会配置) public static SecurityManager getSecurityManager() throws UnavailableSecurityManagerException { SecurityManager securityManager = ThreadContext.getSecurityManager(); if (securityManager == null) { securityManager = SecurityUtils.securityManager; }return securityManager; }

 看到这儿我们了解到了为什么我们在程序中调用SecurityUtils的getSubject会有值了

小结:

  当我们登陆后,每次请求都会将Subject对象和SecurityManager对象与当前线程绑定,在执行完业务逻辑后,会将这些数据与当前线程解绑

  那么我们得到了SecurityManager对象后,那么它依赖的数据就轻而易举的可以愉快的拿到了

注:有不好或者错误的地方还请看官在评论区给指出,意见宝贵。

原文地址:https://www.cnblogs.com/qiaozhuangshi/p/10787823.html