1.什么是免登录功能
当我们的应用需要集成到第三方平台时(比如微信)，第三方平台的账户和我们应用必然不是同一个，为了方便用户使用，我们不可能每次在微信打开我们的H5页面时，都需要进行登录。我们需要做的是，把微信账号和我们应用内的账号进行绑定，绑定过后，进入应用就不需要在登录了。并且修改密码不影响这个免登功能。
2.怎么实现免登功能
在讲什么实现之前，先思考一下，为什么需要登录这个操作，如何保持登录状态
登录操作，通过验证用户名和密码，让系统承认你是对应用户信息的拥有人，并授权做一些操作，简单来讲，登录就是拿到你自己的id，用这个id你可以做一些和自己有关的事情
如何保持登录状态则利用到了Cookie(Cookie不是必须的,也可以用其他方式实现，如Header)和Session
Cookie存在于客户端，用来找到对应的Session
Session存在于服务端，用来维持用户登录状态，内部具体保存内容，见下一节
用户在访问页面后就会生成session以及cookie，但是这个session可以和用户无关，用户执行登录操作后，会绑定用户信息到session中去
session和cookie缺少一者，都需要重新登录
接上文，在与第三方绑定过后，一般会直接进入应用，对应服务器会生成Session，客户端会生成cookie，但是随着时间流逝，要么session会失效(服务器重启什么的),要么cookie会失效(本地清除缓存)，但是我们的需求是，只要绑定过后，从第三方进入应用，就是不需要登录的。
最关键的一点浮出水面了，你知道我们应该做什么事情吗？？
那就是重建Session(跳过登录操作，绑定用户信息到Session)
i流程图
解释下上面的流程图
- 请求应用页的时候，会带上本地的cookie发送到服务器来校验对应session是否存在以及有效，如果有效，正常访问应用页，不需要进行登录或绑定
- 在第1步失败的情况下，会跳转到绑定页面，首先从上下文中拿到第三方userid，请求服务器接口判断是否存在对应用户信息，如果存在，把用户信息绑定到当前session,跳转到目标页。(session在访问绑定页的时候会生成一个)
- 如果第2步找不到用户信息，那么不进行任何跳转，让用户进行绑定操作
绑定操作，主要是把第三方用户id和我们应用内用户id以及其他信息绑定
下面开始源码分析，我们应该如何重建Session，看源码还是有好处的，Shiro没有特别来讲这个东西。
3. Shiro源码分析
3.1 Shiro对session的抽象
session接口
看下Session接口能让我们对Session的理解更加深刻点，主要讲下其中几个属性
id：用来和cookie保存的用户凭证匹配
touch：用来刷新session
stop：用来停止session
attribute: 我们的用户详细信息就保存在这里
3.2 Session的获取与创建
3.2.1 Session的创建
Session的创建由DefaultSessionManager的doCreateSession方法实现
protected Session doCreateSession(SessionContext context) {
Session s = newSessionInstance(context);
if (log.isTraceEnabled()) {
log.trace("Creating session for host {}", s.getHost());
}
create(s);
return s;
}
newSessionInstance方法中使用SessionFactory的createSession创建初始Session
public Session createSession(SessionContext initData) {
if (initData != null) {
String host = initData.getHost();
if (host != null) {
return new SimpleSession(host);
}
}
return new SimpleSession();
}
注意到其实只放了host，sessionID在doCreateSession里的create方法里赋值
protected void create(Session session) {
if (log.isDebugEnabled()) {
log.debug("Creating new EIS record for new session instance [" + session + "]");
}
sessionDAO.create(session);
}
可以看到create方法里使用sessionDAO.create(session)对session进行里处理，我们看下框架提供的AbstractSessionDAO
public Serializable create(Session session) {
Serializable sessionId = doCreate(session);
verifySessionId(sessionId);
return sessionId;
}
这边有个doCreate会返回sessionID，也就是说里面会对session构建sessionid，与此同时，sessionDAO本身的功能，保存session到第三方存储也在这里面实现，我们看下MemorySessionDAO的实现
protected Serializable doCreate(Session session) {
Serializable sessionId = generateSessionId(session);
assignSessionId(session, sessionId);
storeSession(sessionId, session);
return sessionId;
}
3.2.2 Session的获取
Shiro获取Session的逻辑在DefaultSessionManager的resolveSession方法中，过程分为两步
protected Session retrieveSession(SessionKey sessionKey) throws UnknownSessionException {
Serializable sessionId = getSessionId(sessionKey);//1
if (sessionId == null) {
log.debug("Unable to resolve session ID from SessionKey [{}]. Returning null to indicate a " +
"session could not be found.", sessionKey);
return null;
}
Session s = retrieveSessionFromDataSource(sessionId);//2
if (s == null) {
//session ID was provided, meaning one is expected to be found, but we couldn't find one:
String msg = "Could not find session with ID [" + sessionId + "]";
throw new UnknownSessionException(msg);
}
return s;
}
- 获取sessionID
获取SessionID由DefaultWebSessionManager的getSessionId方法实现
protected Serializable getSessionId(ServletRequest request, ServletResponse response) {
return getReferencedSessionId(request, response);
}
再来看下getReferencedSessionId的具体逻辑
private Serializable getReferencedSessionId(ServletRequest request, ServletResponse response) {
String id = getSessionIdCookieValue(request, response);//1
if (id != null) {
request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_SOURCE,
ShiroHttpServletRequest.COOKIE_SESSION_ID_SOURCE);
} else {
//not in a cookie, or cookie is disabled - try the request URI as a fallback (i.e. due to URL rewriting):
//try the URI path segment parameters first:
id = getUriPathSegmentParamValue(request, ShiroHttpSession.DEFAULT_SESSION_ID_NAME);//2
if (id == null) {
//not a URI path segment parameter, try the query parameters:
String name = getSessionIdName();
id = request.getParameter(name);//3
if (id == null) {
//try lowercase:
id = request.getParameter(name.toLowerCase());//4
}
}
if (id != null) {
request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_SOURCE,
ShiroHttpServletRequest.URL_SESSION_ID_SOURCE);
}
}
if (id != null) {
request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID, id);
//automatically mark it valid here. If it is invalid, the
//onUnknownSession method below will be invoked and we'll remove the attribute at that time.
request.setAttribute(ShiroHttpServletRequest.REFERENCED_SESSION_ID_IS_VALID, Boolean.TRUE);
}
return id;
}
逻辑如下
- 通过getSessionIdCookieValue从cookie去获取，获取不到，进入下一步
- 调用getUriPathSegmentParamValue从url的Segement片段获取，获取不到，进入下一步
- 调用request.getParameter从url带的参数中获取，获取不到，进入下一步
- 调用request.getParameter从url带的参数中获取，但是对传入的参数转换为小写
Segement片段,这部分不看源码还真不知道有这东西，在URL中的位置如下，
protocol://host:port/path;segement?param=value
2.获取Session
在拿到SessionId之后就要通过SessionDao获取Session了,先看下retrieveSessionFromDataSource方法
protected Session retrieveSessionFromDataSource(Serializable sessionId) throws UnknownSessionException {
return sessionDAO.readSession(sessionId);
}
委托给了sessionDAO做处理，SessionDAO的主要作用是做Session的持久化存储
SessionDAO
SessionDAO默认实现为MemorySessionDAO,但是我们为了支持集群部署，需要自定义实现，一般使用Redis来扩展
3.3session中用户信息的设置和获取
上面讲了session的创建和获取，其实都不是本文关键点，我最关注的是Session里的用户信息是怎么设置进去的，需要设置哪些内容
用户信息的设置，很明显是登陆过后，我们看下登陆的方法做了什么
入口在DelegatingSubject的login方法
public void login(AuthenticationToken token) throws AuthenticationException {
clearRunAsIdentitiesInternal();
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;
}
}
这边并没有明显的对session的操作，但是我们可以发现
Subject subject = securityManager.login(this, token);
这句代码生成了一个subject，并且后面的代码，会把这个subject的内容替换给当前的subject，比如
Session session = subject.getSession(false);
那么对session设置用户信息的代码肯定在securityManager.login里面
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
}
Subject loggedIn = createSubject(token, info, subject);
onSuccessfulLogin(token, info, loggedIn);
return loggedIn;
}
在这个方法里面，通过createSubject生成了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);
}
使用入参创建了上下文,然后调用上下文为参数的重载方法createSubject(context)
查看DefaultSecurityManager的createSubject(context)方法
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;
}
前面的代码都是设置上下文，创建subject，我们需要的逻辑在save方法里
protected void save(Subject subject) {
this.subjectDAO.save(subject);
}
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;
}
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);
}
终于找到这个看起来很像的saveToSession方法
很明显在mergePrincipals方法里，继续
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) {
if (!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 (isEmpty(currentPrincipals)) {
if (!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
}
}
}
可以观察到用户信息被设置到session的attribute里，key为DefaultSubjectContext.PRINCIPALS_SESSION_KEY
当然mergeAuthenticationState也是必须的
protected void mergeAuthenticationState(Subject subject) {
Session session = subject.getSession(false);
if (session == null) {
if (subject.isAuthenticated()) {
session = subject.getSession();
session.setAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY, Boolean.TRUE);
}
//otherwise no session and not authenticated - nothing to save
} else {
Boolean existingAuthc = (Boolean) session.getAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY);
if (subject.isAuthenticated()) {
if (existingAuthc == null || !existingAuthc) {
session.setAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY, Boolean.TRUE);
}
//otherwise authc state matches - no need to update the session
} else {
if (existingAuthc != null) {
//existing doesn't match the current state - remove it:
session.removeAttribute(DefaultSubjectContext.AUTHENTICATED_SESSION_KEY);
}
//otherwise not in the session and not authenticated - no need to update the session
}
}
}
他会在session里面设置DefaultSubjectContext.AUTHENTICATED_SESSION_KEY，值为true是表示session内的用户信息是验证过后的，有效的
那么我们的问题也解决了，我们只需要把第三方id和用户信息绑定关系存下来，然后在绑定页面渲染之前判断当前第三方id是否绑定了用户信息，如果有，直接在当前session对象塞入这2个内容，并且返回true给前端，让前端执行重定向。重定向到其他子系统的时候，shiro框架会重新根据sessionid去查询session是否有效，此时session已经有效了，能正常访问子系统页面
目标页的系统也集成了我单点登陆的shiro配置，所以会在shirofilter里面校验session是否存在并且有效，然后进入系统，而不是跳转到单点登陆
在我Demo中也模拟了这个免登陆功能
查询用户是否绑定接口代码如下
@GetMapping("/isUserBind")
@ResponseBody
public WebResult isUserBind(@RequestParam("thirdUserId")String thirdUserId){
if(!UserBindInfoCache.containsKey(thirdUserId)){
return new WebResult(null,false);
}
Subject subject =SecurityUtils.getSubject();
Session session = subject.getSession(false);
SessionKey sessionKey = new DefaultSessionKey(session.getId());
Principal principal = UserBindInfoCache.get(thirdUserId);
SimplePrincipalCollection simplePrincipalCollection = new SimplePrincipalCollection(principal, AuthenticationRealm.class.getName());
sessionManager.setAttribute(sessionKey, DefaultSubjectContext.PRINCIPALS_SESSION_KEY,simplePrincipalCollection);
sessionManager.setAttribute(sessionKey, DefaultSubjectContext.AUTHENTICATED_SESSION_KEY,true);
return new WebResult(null,true);
}
前端逻辑代码如下
<script>
//模拟第三方环境
var thirdUserId ="abcd1234";
$(function () {
$.get("/isUserBind",{
thirdUserId:thirdUserId
},function (result) {
if(result.flag==true){
window.location.href = $('#redirectUrl').val();
}else{
$('#bindPage').removeClass('hidden')
}
},"json")
$('#loginButton').click(function (event) {
event.preventDefault()
var username = $('#username').val();
var password = $('#password').val();
var redirectUrl = $('#redirectUrl').val();
$.post("/bind",{
username:username,
password:password,
thirdUserId:thirdUserId
},function (result) {
console.log(JSON.stringify(result));
if(result.flag==true){
window.location.href=redirectUrl;
}
},"json")
})
})
</script>
