认证服务(Oauth、分布式集群session共享问题、单点登录)

1.注册

好玩的代码倒计时

1.页面js提交注册请求到认证服务

自定义视图映射将无实际业务意义只进行页面跳转的请求抽取到viewcontroller中

路径映射默认都是get访问的

使用阿里云的短信验证码

参考第三发接口文档,原理就是请求短信服务地址并设置http的请求头(服务地址,appcode,和method)和参数(验证码,模板,公司签名,手机号)

此处应注意不应该是页面直接短服务,而是页面ajax请求认证服务,认证服务远程调用短信服务发送验证码
注册页调用

2.认证服务的远程调用第三方短信服务发送短信并存入缓存并返回注册页面(接口防刷：配合redis实现验证码的再校验)

3.提交注册表单到会员服务,验证通过进行数据库持久化
防止注册表单重复提交
注册成功后使用重定向防止注册表单重复提交,可使用RedirectAttribute redirectAttribute代替Model mode作为参数 为重定携带数据,利用session,将数据放到session中只要跳到下一个页面取出这个数据,session里面的数据就会被删除

持久化代码

md5盐值加密

spring提供的加密器的加密与匹配

登录

页面提交请求到认证服务,认证服务远程调用member

2.社交登录

2.1OAuth2.0简介

2.2微博登录示例

2.2.1.进入微博开放平台

创建微连接设置应用名称等信息,设置回调地址(回调地址就是我们自己开发的应用)

2.2.2.基本使用流程

1.引导需要授权的用户到如下地址：替换下面的client_id为我们应用的App Key,替换redirect_uri为我们的商城应用

https://api.weibo.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI

2.如果用户同意授权，页面跳转至 YOUR_REGISTERED_REDIRECT_URI/?code=CODE

3.换取Access Token(一个code只能换取一个Access Token)
client_id: 申请应用时分配的AppKey。
client_secret:申请应用时分配的AppSecret。
grant_type:请求的类型，填写authorization_code
redirect_uri: 回调地址，需需与注册应用里的回调地址一致。
code:第二步获取的code值

https://api.weibo.com/oauth2/access_token?client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=authorization_code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI&code=CODE

拿到Access Token之后就可以使用Access Token去访问所有微博提供的接口并获取信息

在调用微博接口时应注意要保证client_secret及Access Token的安全性(不可暴露)。

2.3示例:

2.3.1.接受页面请求,根据code换取包含Access Token信息的json数据

2.3.2.处理包含Access Token信息的json数据

1.使用json(包含Access Token)在线格式转换将json转为javabean,并放入项目中


2.处理json(包含Access Token)转为我们生成的bean

2.2.3.处理社交用户是登录还是注册

根据json信息获取社交应用中的用户信息并插入数据库
使用json数据中的uid作为该微博帐户关联wwmall应用的唯一标识
每次使用社交登陆获取的Access Token值会变,但uid是相同的所以我们用uid关联社交应用与我们的应用
判断当前社交用户是否登陆过,如果是第一次就注册在系统中,如果不是第一次就直接登录

2.2.4.登录成功返回登录

登录成功将用户信息放入session中

2.4session 不共享问题

分布式session出现不共享原因
session原理

假如我们现在通过认证中心，登陆后cookie存储了我们的jsessionid但是他的作用域是在我们认证中心的域名下为auth.wwmall.com,而我们访问会员服务域名为memeber.wwmall.com并不会携带我们存在认证中心的cookie 即cookie不能跨不同域名共享
由于session的原理导致在分布式集群应用环境下导致session不共享问题

2.5分布式session共享解决方案

2.5.1集群服务session不共享解决方案()

2.5.1.1session赋值方案(高集群环境下不可取)

2.5.1.2session存储在客户端中(不安全,cookie存储内容有上限)

2.5.1.3利用负载均衡机制(使用IP的hash一致性)将同一个用户的请求负载均衡到同一服务

2.5.1.4最终解决方案:统一存储到redis中

2.5.2分布式应用session不共享解决方案

父域名wwmall.com ,子域名auth.wwmall.com, 子域名product.wwmall.com
子域名之间cookie是不能共享的。

2.5.2.1子域session共享

我们在存取session时将浏览器需要存储的cookie域名都指定为父域名 （通过指定domain的属性值）

2.5.2.2整合spring session解决session跨域问题

引入依赖

<dependency>
	<groupId>org.springframework.session</groupId>
	<artifactId>spring-session-data-redis</artifactId>
</dependency>

配置文件配置

spring.session.store-type=redis ＃会话存储类型。
server.servlet.session.timeout =＃会话超时。如果未指定持续时间后缀，则使用秒。
spring.session.redis.flush-mode = on_save＃会话刷新模式。
spring.session.redis.namespace = spring：session＃用于存储会话的键的命名空间

在主类上使用@EnableRedisHttpSession

编写配置类设置cookie的domian属性,并设置序列化到redis的规则使用阿里提供的序列化器

修改业务代码登录成功给session域中放数据

2.5.2.3springsession核心原理(使用装饰者模式将原生的request包装以后,想获取session都去包装后的request中获取，包装后的session中是对redis中session的操作)

3.多系统-----单点登录

第一次到认证中心登录成功,给redis存储一个seseion信息，给页面中的认证中心域名下写一个cookie中存入token，
其他系统登录访问认证中心，就会直接携带第一步存入浏览器的cookie，判断是否携带token，若携带token，去redis中校验当前token是否有效，若有效，直接携带这个token跳回原来访问系统的页面，并在自己的服务器上创建一个session，下次请求直接携带token在自己的认证服务器上

4. 自定义注解实现登录检查

自定义注解:

自定义拦截器

拦截器放行规则

将拦截器注入spring并定义拦截器拦截规则
注: SpringBoot2.0版本使用继承WebMvcConfigurationSupport 来扩展SpringMvc的功能

webmvc中常用方法

使用自定义注解标注在类上即可