`

shiro源码分析(二)Subject和Session

阅读更多
继续上一篇文章的案例,第一次使用SecurityUtils.getSubject()来获取Subject时
public static Subject getSubject() {
        Subject subject = ThreadContext.getSubject();
        if (subject == null) {
            subject = (new Subject.Builder()).buildSubject();
            ThreadContext.bind(subject);
        }
        return subject;
    }
 
使用ThreadLocal模式来获取,若没有则创建一个并绑定到当前线程。此时创建使用的是Subject内部类Builder来创建的,Builder会创建一个SubjectContext接口的实例DefaultSubjectContext,最终会委托securityManager来根据SubjectContext信息来创建一个Subject,下面详细说下该过程,在DefaultSecurityManager的createSubject方法中:
public Subject createSubject(SubjectContext subjectContext) {
        SubjectContext context = copy(subjectContext);

        context = ensureSecurityManager(context);

        context = resolveSession(context);

        context = resolvePrincipals(context);

        Subject subject = doCreateSubject(context);

        save(subject);

        return subject;
    }

首先就是复制SubjectContext,SubjectContext 接口继承了Map<String, Object>,然后加入了几个重要的SecurityManager、SessionId、Subject、PrincipalCollection、Session、boolean authenticated、boolean sessionCreationEnabled、Host、AuthenticationToken、AuthenticationInfo等众多信息。

然后来讨论下接口设计:



讨论1:首先是SubjectContext为什么要去实现Map<String, Object>?
SubjectContext提供了常用的get、set方法,还提供了一个resolve方法,以SecurityManager为例:

   SecurityManager getSecurityManager();

    void setSecurityManager(SecurityManager securityManager);

    SecurityManager resolveSecurityManager();

这些get、set方法则用于常用的设置和获取,而resolve则表示先调用getSecurityManager,如果获取不到,则使用其他途径来获取,如DefaultSubjectContext的实现:
public SecurityManager resolveSecurityManager() {
        SecurityManager securityManager = getSecurityManager();
        if (securityManager == null) {
            if (log.isDebugEnabled()) {
                log.debug("No SecurityManager available in subject context map.  " +
                        "Falling back to SecurityUtils.getSecurityManager() lookup.");
            }
            try {
                securityManager = SecurityUtils.getSecurityManager();
            } catch (UnavailableSecurityManagerException e) {
                if (log.isDebugEnabled()) {
                    log.debug("No SecurityManager available via SecurityUtils.  Heuristics exhausted.", e);
                }
            }
        }
        return securityManager;
    }

如果getSecurityManager获取不到,则使用SecurityUtils工具来获取。
再如resolvePrincipals

public PrincipalCollection resolvePrincipals() {
        PrincipalCollection principals = getPrincipals();

        if (CollectionUtils.isEmpty(principals)) {
            //check to see if they were just authenticated:
            AuthenticationInfo info = getAuthenticationInfo();
            if (info != null) {
                principals = info.getPrincipals();
            }
        }

        if (CollectionUtils.isEmpty(principals)) {
            Subject subject = getSubject();
            if (subject != null) {
                principals = subject.getPrincipals();
            }
        }

        if (CollectionUtils.isEmpty(principals)) {
            //try the session:
            Session session = resolveSession();
            if (session != null) {
                principals = (PrincipalCollection) session.getAttribute(PRINCIPALS_SESSION_KEY);
            }
        }

        return principals;
    }

普通的getPrincipals()获取不到,尝试使用其他属性来获取。
讨论2:此时就有一个问题,有必要再对外公开getPrincipals方法吗?什么情况下外界会去调用getPrincipals方法而不会去调用resolvePrincipals方法?

然后我们继续回到上面的类图设计上:
DefaultSubjectContext继承了MapContext,MapContext又实现了Map<String, Object>,看下此时的MapContext有什么东西:

public class MapContext implements Map<String, Object>, Serializable {

    private static final long serialVersionUID = 5373399119017820322L;

    private final Map<String, Object> backingMap;

    public MapContext() {
        this.backingMap = new HashMap<String, Object>();
    }

    public MapContext(Map<String, Object> map) {
        this();
        if (!CollectionUtils.isEmpty(map)) {
            this.backingMap.putAll(map);
        }
    }
  //略
}

MapContext内部拥有一个类型为HashMap的backingMap属性,大部分方法都由HashMap来实现,然后仅仅更改某些行为,MapContext没有选择去继承HashMap,而是使用了组合的方式,更加容易去扩展,如backingMap的类型不一定非要选择HashMap,可以换成其他的Map实现,一旦MapContext选择继承HashMap,如果想对其他的Map类型进行同样的功能增强的话,就需要另写一个类来继承它然后改变一些方法实现,这样的话就会有很多重复代码。这也是设计模式所强调的少用继承多用组合。但是MapContext的写法使得子类没法去替换HashMap,哎,心塞
MapContext又提供了如下几个返回值不可修改的方法:

public Set<String> keySet() {
        return Collections.unmodifiableSet(backingMap.keySet());
    }

    public Collection<Object> values() {
        return Collections.unmodifiableCollection(backingMap.values());
    }

    public Set<Entry<String, Object>> entrySet() {
        return Collections.unmodifiableSet(backingMap.entrySet());
    }

有点扯远了。继续回到DefaultSecurityManager创建Subject的地方:
public Subject createSubject(SubjectContext subjectContext) {
        //create a copy so we don't modify the argument's backing map:
        SubjectContext context = copy(subjectContext);

        //ensure that the context has a SecurityManager instance, and if not, add one:
        context = ensureSecurityManager(context);

        //Resolve an associated Session (usually based on a referenced session ID), and place it in the context before
        //sending to the SubjectFactory.  The SubjectFactory should not need to know how to acquire sessions as the
        //process is often environment specific - better to shield the SF from these details:
        context = resolveSession(context);

        //Similarly, the SubjectFactory should not require any concept of RememberMe - translate that here first
        //if possible before handing off to the SubjectFactory:
        context = resolvePrincipals(context);

        Subject subject = doCreateSubject(context);

        //save this subject for future reference if necessary:
        //(this is needed here in case rememberMe principals were resolved and they need to be stored in the
        //session, so we don't constantly rehydrate the rememberMe PrincipalCollection on every operation).
        //Added in 1.2:
        save(subject);

        return subject;
    }

对于context,把能获取到的参数都凑齐,SecurityManager、Session。resolveSession尝试获取context的map中获取Session,若没有则尝试获取context的map中的Subject,如果存在的话,根据此Subject来获取Session,若没有再尝试获取sessionId,若果有了sessionId则构建成一个DefaultSessionKey来获取对应的Session。
整个过程如下;

protected SubjectContext resolveSession(SubjectContext context) {
        if (context.resolveSession() != null) {
            log.debug("Context already contains a session.  Returning.");
            return context;
        }
        try {
            //Context couldn't resolve it directly, let's see if we can since we have direct access to 
            //the session manager:
            Session session = resolveContextSession(context);
            if (session != null) {
                context.setSession(session);
            }
        } catch (InvalidSessionException e) {
            log.debug("Resolved SubjectContext context session is invalid.  Ignoring and creating an anonymous " +
                    "(session-less) Subject instance.", e);
        }
        return context;
    }

先看下context.resolveSession():
public Session resolveSession() {
  //这里则是直接从map中取出Session
        Session session = getSession();
        if (session == null) {
            //try the Subject if it exists:
           //若果没有,尝试从map中取出Subject 
            Subject existingSubject = getSubject();
            if (existingSubject != null) {
                //这里就是Subject获取session的方法,需要详细看下
                session = existingSubject.getSession(false);
            }
        }
        return session;
    }

existingSubject.getSession(false):通过Subject获取Session如下
public Session getSession(boolean create) {
        if (log.isTraceEnabled()) {
            log.trace("attempting to get session; create = " + create +
                    "; session is null = " + (this.session == null) +
                    "; session has id = " + (this.session != null && session.getId() != null));
        }

        if (this.session == null && create) {

            //added in 1.2:
            if (!isSessionCreationEnabled()) {
                String msg = "Session creation has been disabled for the current subject.  This exception indicates " +
                        "that there is either a programming error (using a session when it should never be " +
                        "used) or that Shiro's configuration needs to be adjusted to allow Sessions to be created " +
                        "for the current Subject.  See the " + DisabledSessionException.class.getName() + " JavaDoc " +
                        "for more.";
                throw new DisabledSessionException(msg);
            }

            log.trace("Starting session for host {}", getHost());
            SessionContext sessionContext = createSessionContext();
            Session session = this.securityManager.start(sessionContext);
            this.session = decorate(session);
        }
        return this.session;
    }

getSession()的参数表示是否创建session,如果Session为空,并且传递的参数为true,则会创建一个Session。然而这里传递的是false,也就是说不会在创建Subject的时候来创建Session,所以把创建Session过程说完后,再回到此处是要记着不会去创建一个Session。但是我们可以来看下是如何创建Session的,整体三大步骤,先创建一个SessionContext ,然后根据SessionContext 来创建Session,最后是装饰Session,由于创建Session过程内容比较多,先说说装饰Session。
protected Session decorate(Session session) {
        if (session == null) {
            throw new IllegalArgumentException("session cannot be null");
        }
        return new StoppingAwareProxiedSession(session, this);
    }

装饰Session就是讲Session和DelegatingSubject封装起来。
然后来说Session的创建过程,这和Subject的创建方式差不多。
同样是SessionContext的接口设计:



和SubjectContext相当雷同。
看下SessionContext的主要内容:

void setHost(String host);
    String getHost();

    Serializable getSessionId();

    void setSessionId(Serializable sessionId);

主要两个内容,host和sessionId。
接下来看下如何由SessionContext来创建Session:

protected Session doCreateSession(SessionContext context) {
        Session s = newSessionInstance(context);
        if (log.isTraceEnabled()) {
            log.trace("Creating session for host {}", s.getHost());
        }
        create(s);
        return s;
    }

    protected Session newSessionInstance(SessionContext context) {
        return getSessionFactory().createSession(context);
    }

和Subject一样也是由一个SessionFactory根据SessionContext来创建出一个Session,看下默认的SessionFactory SimpleSessionFactory的创建过程:
public Session createSession(SessionContext initData) {
        if (initData != null) {
            String host = initData.getHost();
            if (host != null) {
                return new SimpleSession(host);
            }
        }
        return new SimpleSession();
    }

如果SessionContext有host信息,就传递给Session,然后就是直接new一个Session接口的实现SimpleSession,先看下Session接口有哪些内容:
public interface Session {
    Serializable getId();
    Date getStartTimestamp();
    Date getLastAccessTime();
    long getTimeout() throws InvalidSessionException;
    void setTimeout(long maxIdleTimeInMillis) throws InvalidSessionException;
    String getHost();
    void touch() throws InvalidSessionException;
    void stop() throws InvalidSessionException;
    Collection<Object> getAttributeKeys() throws InvalidSessionException;
    Object getAttribute(Object key) throws InvalidSessionException;
    void setAttribute(Object key, Object value) throws InvalidSessionException;
    Object removeAttribute(Object key) throws InvalidSessionException;
}

id:Session的唯一标识,创建时间、超时时间等内容。
再看SimpleSession的创建过程:

public SimpleSession() {
        this.timeout = DefaultSessionManager.DEFAULT_GLOBAL_SESSION_TIMEOUT;
        this.startTimestamp = new Date();
        this.lastAccessTime = this.startTimestamp;
    }

    public SimpleSession(String host) {
        this();
        this.host = host;
    }

设置下超时时间为DefaultSessionManager.DEFAULT_GLOBAL_SESSION_TIMEOUT 30分钟,startTimestamp 和lastAccessTime设置为现在开始。就这样构建出了一个Session的实例,然后就是需要将该实例保存起来:
protected Session doCreateSession(SessionContext context) {
        Session s = newSessionInstance(context);
        if (log.isTraceEnabled()) {
            log.trace("Creating session for host {}", s.getHost());
        }
        create(s);
        return s;
    }
protected void create(Session session) {
        if (log.isDebugEnabled()) {
            log.debug("Creating new EIS record for new session instance [" + session + "]");
        }
        sessionDAO.create(session);
    }

即该进行create(s)操作了,又和Subject极度的相像,使用sessionDAO来保存刚才创建的Session。再来看下SessionDAO接口:
public interface SessionDAO {
    Serializable create(Session session);
    Session readSession(Serializable sessionId) throws UnknownSessionException;
    void update(Session session) throws UnknownSessionException;
    void delete(Session session);
    Collection<Session> getActiveSessions();
}

也就是对所有的Session进行增删该查,SessionDAO 接口继承关系如下:


AbstractSessionDAO:有一个重要的属性SessionIdGenerator,它负责给Session创建sessionId,SessionIdGenerator接口如下:
public interface SessionIdGenerator {
    Serializable generateId(Session session);
}

很简单,参数为Session,返回sessionId。SessionIdGenerator 的实现有两个JavaUuidSessionIdGenerator、RandomSessionIdGenerator。而AbstractSessionDAO默认采用的是JavaUuidSessionIdGenerator,如下:
public AbstractSessionDAO() {
        this.sessionIdGenerator = new JavaUuidSessionIdGenerator();
    }

MemorySessionDAO继承了AbstractSessionDAO,它把Session存储在一个ConcurrentMap<Serializable, Session> sessions集合中,key为sessionId,value为Session。
CachingSessionDAO:主要配合在别的地方存储session。先不介绍,之后的文章再详细说。
对于本案例来说SessionDAO为MemorySessionDAO。至此整个Session的创建过程就走通了。

刚才虽然说了整个Session的创建过程,回到上文所说的,不会去创建Session的地方。在创建Subject搜集session信息时,使用的此时的Subject的Session、sessionId都为空,所以获取不到Session。然后就是doCreateSubject:

protected Subject doCreateSubject(SubjectContext context) {
        return getSubjectFactory().createSubject(context);
    }

就是通过SubjectFactory工厂接口来创建Subject的,而DefaultSecurityManager默认使用的
SubjectFactory是DefaultSubjectFactory:

public DefaultSecurityManager() {
        super();
        this.subjectFactory = new DefaultSubjectFactory();
        this.subjectDAO = new DefaultSubjectDAO();
    }

继续看DefaultSubjectFactory是怎么创建Subject的:
public Subject createSubject(SubjectContext context) {
        SecurityManager securityManager = context.resolveSecurityManager();
        Session session = context.resolveSession();
        boolean sessionCreationEnabled = context.isSessionCreationEnabled();
        PrincipalCollection principals = context.resolvePrincipals();
        boolean authenticated = context.resolveAuthenticated();
        String host = context.resolveHost();

        return new DelegatingSubject(principals, authenticated, host, session, sessionCreationEnabled, securityManager);
    }

仍然就是将这些属性传递给DelegatingSubject,也没什么好说的。创建完成之后,就需要将刚创建的Subject保存起来,仍回到:
public Subject createSubject(SubjectContext subjectContext) {
        //create a copy so we don't modify the argument's backing map:
        SubjectContext context = copy(subjectContext);

        //ensure that the context has a SecurityManager instance, and if not, add one:
        context = ensureSecurityManager(context);

        //Resolve an associated Session (usually based on a referenced session ID), and place it in the context before
        //sending to the SubjectFactory.  The SubjectFactory should not need to know how to acquire sessions as the
        //process is often environment specific - better to shield the SF from these details:
        context = resolveSession(context);

        //Similarly, the SubjectFactory should not require any concept of RememberMe - translate that here first
        //if possible before handing off to the SubjectFactory:
        context = resolvePrincipals(context);

        Subject subject = doCreateSubject(context);

        //save this subject for future reference if necessary:
        //(this is needed here in case rememberMe principals were resolved and they need to be stored in the
        //session, so we don't constantly rehydrate the rememberMe PrincipalCollection on every operation).
        //Added in 1.2:
        save(subject);

        return subject;
    }

来看下save方法:
protected void save(Subject subject) {
        this.subjectDAO.save(subject);
    }

可以看到又是使用另一个模块来完成的即SubjectDAO,SubjectDAO接口如下:
public interface SubjectDAO {
    Subject save(Subject subject);
    void delete(Subject subject);
}

很简单,就是保存和删除一个Subject。我们看下具体的实现类DefaultSubjectDAO是如何来保存的:
public Subject save(Subject subject) {
        if (isSessionStorageEnabled(subject)) {
            saveToSession(subject);
        } else {
            log.trace("Session storage of subject state for Subject [{}] has been disabled: identity and " +
                    "authentication state are expected to be initialized on every request or invocation.", subject);
        }

        return subject;
    }

首先就是判断isSessionStorageEnabled,是否要存储该Subject的session来
DefaultSubjectDAO:有一个重要属性SessionStorageEvaluator,它是用来决定一个Subject的Session来记录Subject的状态,接口如下

public interface SessionStorageEvaluator {
    boolean isSessionStorageEnabled(Subject subject);
}

其实现为DefaultSessionStorageEvaluator:
public class DefaultSessionStorageEvaluator implements SessionStorageEvaluator {

    private boolean sessionStorageEnabled = true;

    public boolean isSessionStorageEnabled(Subject subject) {
        return (subject != null && subject.getSession(false) != null) || isSessionStorageEnabled();
    }

决定策略就是通过DefaultSessionStorageEvaluator 的sessionStorageEnabled的true或false 和subject是否有Session对象来决定的。如果允许存储Subject的Session的话,下面就说具体的存储过程:
protected void saveToSession(Subject subject) {
        //performs merge logic, only updating the Subject's session if it does not match the current state:
        mergePrincipals(subject);
        mergeAuthenticationState(subject);
    }
protected void mergePrincipals(Subject subject) {
        //merge PrincipalCollection state:

        PrincipalCollection currentPrincipals = null;

        //SHIRO-380: added if/else block - need to retain original (source) principals
        //This technique (reflection) is only temporary - a proper long term solution needs to be found,
        //but this technique allowed an immediate fix that is API point-version forwards and backwards compatible
        //
        //A more comprehensive review / cleaning of runAs should be performed for Shiro 1.3 / 2.0 +
        if (subject.isRunAs() && subject instanceof DelegatingSubject) {
            try {
                Field field = DelegatingSubject.class.getDeclaredField("principals");
                field.setAccessible(true);
                currentPrincipals = (PrincipalCollection)field.get(subject);
            } catch (Exception e) {
                throw new IllegalStateException("Unable to access DelegatingSubject principals property.", e);
            }
        }
        if (currentPrincipals == null || currentPrincipals.isEmpty()) {
            currentPrincipals = subject.getPrincipals();
        }

        Session session = subject.getSession(false);

        if (session == null) {
           //只有当Session为空,并且currentPrincipals不为空的时候才会去创建Session
           //Subject subject = SecurityUtils.getSubject()此时两者都是为空的,
           //不会去创建Session
            if (!CollectionUtils.isEmpty(currentPrincipals)) {
                session = subject.getSession();
                session.setAttribute(DefaultSubjectContext.PRINCIPALS_SESSION_KEY, currentPrincipals);
            }
            //otherwise no session and no principals - nothing to save
        } else {
            PrincipalCollection existingPrincipals =
                    (PrincipalCollection) session.getAttribute(DefaultSubjectContext.PRINCIPALS_SESSION_KEY);

            if (CollectionUtils.isEmpty(currentPrincipals)) {
                if (!CollectionUtils.isEmpty(existingPrincipals)) {
                    session.removeAttribute(DefaultSubjectContext.PRINCIPALS_SESSION_KEY);
                }
                //otherwise both are null or empty - no need to update the session
            } else {
                if (!currentPrincipals.equals(existingPrincipals)) {
                    session.setAttribute(DefaultSubjectContext.PRINCIPALS_SESSION_KEY, currentPrincipals);
                }
                //otherwise they're the same - no need to update the session
            }
        }
    }

上面有我们关心的重点,当subject.getSession(false)获取的Session为空时(它不会去创建Session),此时就需要去创建Session,subject.getSession()则默认调用的是subject.getSession(true),则会进行Session的创建,创建过程上文已详细说明了。
在第一次创建Subject的时候

 Subject subject = SecurityUtils.getSubject();  

虽然Session为空,但此时还没有用户身份信息,也不会去创建Session。案例中的subject.login(token),该过程则会去创建Session,具体看下过程:
public Subject login(Subject subject, AuthenticationToken token) throws AuthenticationException {
        AuthenticationInfo info;
        try {
            info = authenticate(token);
        } catch (AuthenticationException ae) {
            try {
                onFailedLogin(token, ae, subject);
            } catch (Exception e) {
                if (log.isInfoEnabled()) {
                    log.info("onFailedLogin method threw an " +
                            "exception.  Logging and propagating original AuthenticationException.", e);
                }
            }
            throw ae; //propagate
        }
         //在该过程会进行Session的创建
        Subject loggedIn = createSubject(token, info, subject);

        onSuccessfulLogin(token, info, loggedIn);

        return loggedIn;
    }

对于验证过程上篇文章已经简单说明了,这里不再说明,重点还是在验证通过后,会设置Subject的身份,即用户名:
protected Subject createSubject(AuthenticationToken token, AuthenticationInfo info, Subject existing) {
        SubjectContext context = createSubjectContext();
        context.setAuthenticated(true);
        context.setAuthenticationToken(token);
        context.setAuthenticationInfo(info);
        if (existing != null) {
            context.setSubject(existing);
        }
        return createSubject(context);
    }

有了认证成功的AuthenticationInfo信息,SubjectContext在resolvePrincipals便可以获取用户信息,即通过AuthenticationInfo的getPrincipals()来获得。
public PrincipalCollection resolvePrincipals() {
        PrincipalCollection principals = getPrincipals();

        if (CollectionUtils.isEmpty(principals)) {
            //check to see if they were just authenticated:
            AuthenticationInfo info = getAuthenticationInfo();
            if (info != null) {
                principals = info.getPrincipals();
            }
        }

        if (CollectionUtils.isEmpty(principals)) {
            Subject subject = getSubject();
            if (subject != null) {
                principals = subject.getPrincipals();
            }
        }

        if (CollectionUtils.isEmpty(principals)) {
            //try the session:
            Session session = resolveSession();
            if (session != null) {
                principals = (PrincipalCollection) session.getAttribute(PRINCIPALS_SESSION_KEY);
            }
        }

        return principals;
    }

PrincipalCollection不为空了,在save(subject)的时候会得到session为空,同时PrincipalCollection不为空,则会执行Session的创建。也就是说在认证通过后,会执行Session的创建,Session创建完成之后会进行一次装饰,即用StoppingAwareProxiedSession将创建出来的session和subject关联起来,然后又进行如下操作:
public void login(AuthenticationToken token) throws AuthenticationException {
        clearRunAsIdentitiesInternal();
        //这里的Subject则是经过认证后创建的并且也含有刚才创建的session,类型为
        //StoppingAwareProxiedSession,即是该subject本身和session的合体。
        Subject subject = securityManager.login(this, token);

        PrincipalCollection principals;

        String host = null;

        if (subject instanceof DelegatingSubject) {
            DelegatingSubject delegating = (DelegatingSubject) subject;
            //we have to do this in case there are assumed identities - we don't want to lose the 'real' principals:
            principals = delegating.principals;
            host = delegating.host;
        } else {
            principals = subject.getPrincipals();
        }

        if (principals == null || principals.isEmpty()) {
            String msg = "Principals returned from securityManager.login( token ) returned a null or " +
                    "empty value.  This value must be non null and populated with one or more elements.";
            throw new IllegalStateException(msg);
        }
        this.principals = principals;
        this.authenticated = true;
        if (token instanceof HostAuthenticationToken) {
            host = ((HostAuthenticationToken) token).getHost();
        }
        if (host != null) {
            this.host = host;
        }
        Session session = subject.getSession(false);
        if (session != null) {
            //在这里可以看到又进行了一次装饰
            this.session = decorate(session);
        } else {
            this.session = null;
        }
    }

subject 创建出来之后,暂且叫内部subject,就是把认证通过的内部subject的信息和session复制给我们外界使用的subject.login(token)的subject中,这个subject暂且叫外部subject,看下session的赋值,又进行了一次装饰,这次装饰则把session(类型为StoppingAwareProxiedSession,即是内部subject和session的合体)和外部subject绑定到一起。
最后来总结下,首先是Subject和Session的接口类图:


然后就是Subject subject = SecurityUtils.getSubject()的一个简易的流程图:


最后是subject.login(token)的简易流程图:





作者:乒乓狂魔
  • 大小: 4.5 KB
  • 大小: 4.4 KB
  • 大小: 5.1 KB
  • 大小: 23.5 KB
  • 大小: 24.5 KB
  • 大小: 16.3 KB
  • 大小: 22.1 KB
分享到:
评论
1 楼 edison87915 2014-12-15  
  

相关推荐

    shiro源码分析二

    Apache Shiro是一个强大的、易于使用的Java安全框架,它提供了认证、授权、会话管理以及加密功能。...通过源码分析,我们可以深入理解Shiro的工作原理和架构设计,从而在实际开发中更加有效地运用Shiro进行安全控制。

    shiro源码分析(四)具体的Realm

    在“shiro源码分析(四)具体的Realm”这一主题中,我们将深入探讨Shiro的核心组件——Realm,它是Shiro与应用程序安全数据源交互的桥梁。 Realm在Shiro中的地位至关重要,它负责验证用户身份并执行授权操作。 ...

    shiro源码包

    - **源码分析**:通过阅读Shiro的源码,可以理解其内部的工作机制,包括如何进行身份验证、授权以及会话管理,有助于定制化开发和性能优化。 - **设计模式**:Shiro的源码中大量运用了设计模式,如工厂模式、代理...

    shiro源码 1.2正式版 编译通过

    4. **会话管理(Session Management)**:Shiro 可以跨Web和非Web应用管理会话,提供会话监听器和超时控制等功能,有助于实现分布式会话。 在1.2版本中,可能包含以下特性: - **兼容性**:由于你提到是在JDK6环境...

    shiro源码分析(六)CredentialsMatcher 的案例分析

    在"Shiro源码分析(六)CredentialsMatcher 的案例分析"这篇博文中,作者深入剖析了Shiro中用于验证用户凭证的`CredentialsMatcher`组件。下面我们将详细探讨这一核心机制及其相关知识点。 1. **CredentialsMatcher...

    Shiro1.2.2_源码(压缩包)

    通过对 Shiro1.2.2 的源码分析,我们可以了解到它如何处理各种安全问题,以及如何构建高效、灵活的安全架构。同时,源码的学习有助于我们理解和解决在实际开发中遇到的安全问题,提升我们的编程技能。

    jsp+数据库+shiro 源码及文档

    通过阅读文档和分析源码,我们可以了解Shiro如何与JSP和数据库协作,如何实现用户认证、授权,以及如何定制Shiro以适应特定项目需求。对于Java Web开发者来说,掌握这些知识能提升应用的安全性和用户体验。

    跟我学Shiro源码

    "跟我学Shiro源码"这个主题旨在深入理解Shiro的工作原理,通过分析源码来提升我们对安全编程的认知。 1. **Shiro架构** Shiro 的核心组件包括 Realm(认证与授权信息源)、SecurityManager(安全管理器)、Subject...

    shiro框架学习视频以及文档和源码

    同时,文档和源码分析将帮助你深入理解Shiro的内部机制,有助于进行定制化开发。 通过观看"尚硅谷Shiro视频",你应该能够学会如何使用Shiro来保护你的Java应用,确保用户数据的安全,以及提供个性化的权限控制策略...

    shiro-root-1.7.0_ROOT_shirocore1.7_shiro1.7源码_

    - **Authorization**: 分析`org.apache.shiro.authz`包,了解权限和角色的处理逻辑。 - **Session Management**: 研究`org.apache.shiro.session`和`org.apache.shiro.session.mgt`包,理解Shiro如何管理和存储会话...

    shiro-root-1.2.3-source-release源码带注释.rar

    通过分析源码,你可以了解到如何在实际项目中配置和使用Shiro,例如设置安全配置、编写自定义 Realm 或 Filter,以及处理会话过期等问题。 总之,“shiro-root-1.2.3-source-release”源码不仅展示了Shiro的架构和...

    shiro_ex源码

    Apache Shiro 是一个强大且易用的Java安全框架,提供...通过阅读和分析源码,你可以深入理解Shiro的核心组件和工作流程,为自己的项目构建安全框架打下坚实的基础。记得在实践中不断探索和调整,以适应不同的安全需求。

    Shiro入门到精通

    总的来说,“Shiro入门到精通”课程覆盖了从基础概念到高级特性的全面内容,结合源码分析和Spring Security的对比,将使你对Shiro有深入的理解,能够在实际项目中灵活运用。无论你是初学者还是有经验的开发者,都能...

    shiro资料shiro资料

    通过阅读`shiro源码分析(pdf+word)`,你可以深入探究Shiro的内部机制,如`RememberMe`服务、会话管理器的工作流程,以及加密算法的应用等。 总的来说,Apache Shiro是一个全面且易用的Java安全框架,适合各种规模...

    Apache Shiro 身份认证例子-源码

    Apache Shiro 是一个强大且易用的 Java 安全框架,它提供了身份认证、授权、加密和...通过分析和理解这个源码示例,你将能够更好地掌握 Apache Shiro 在实际项目中的应用,为你的 Java 应用提供可靠的身份认证机制。

    Shiro入门源码

    Apache Shiro 是一个强大且易用的...通过分析Shiro源码,我们可以了解其内部机制,更好地定制和扩展Shiro以满足项目的特定需求。同时,结合Spring框架的整合,可以使Shiro的功能更加强大,提高应用的安全性和可维护性。

    spring mvc整合shiro登录 权限验证实例下载

    8. **源码分析**:提供的abel_shiro压缩包中的源码可以作为学习和参考的实例,通过阅读源码,理解Shiro如何与Spring MVC协同工作,如何处理登录、注销以及权限验证的具体流程。 总之,Spring MVC和Shiro的整合使...

    跟我一起学shiro 张开涛

    Shiro的基础概念包括Subject、Realms、Cryptography和Session。Subject是Shiro的核心,代表了当前的用户或安全实体;Realms则负责与数据源交互,获取认证和授权信息;Cryptography部分则提供了加密工具,确保数据的...

    Shiro maven 完整案例代码

    它的核心组件包括 Subject、SecurityManager、Realms 和 Caches,其中 Subject 表示当前操作用户,SecurityManager 是 Shiro 的心脏,它管理着所有与安全相关的操作;Realms 是连接应用数据源获取凭证和权限信息的...

    Shiro集成OAuth2

    6. **源码分析**: 分析`oauth2_oltu`中的代码,可以深入理解OAuth2的实现细节以及如何将其与Shiro整合。通过阅读客户端配置、授权逻辑和令牌管理部分的代码,可以掌握实际的开发流程。 在实际应用中,开发者需要...

Global site tag (gtag.js) - Google Analytics