1.3 部署UAA认证服务
1.4 认证拦截功能实现
1.4.1 需求分析 前面我们已经接触过、使用过网关服务(gateway-server)，该服务目前只是做了路由转发，并没有起到 真正网关的作用，现在终于有了用武之地，接下来网关服务要在P2P认证授权体系里负责两件事：
（1）令牌解析并转发当前登录用户信息给微服务
（2）作为OAuth2.0的资源服务器角色，实现接入方权限拦截
业务流程图
1.4.2 环境准备 此功能同样涉及到Spring Security OAuth2，不做过多介绍，作为基础功能直接提供给大家使用。
（3）在gateway-server工程中的ResouceServerConfig类里定义资源服务配置，主要配置的内容就是 定义一些匹配规则，描述某个接入客户端需要什么样的权限才能访问某个微服务。
如果网关接收到的请求url符合/consumer/**表达式，该请求将被转发至consumer-service(用户中 心)。为了便于权限拦截，我们将微服务内部的接口进行了细分，大体分为三类： 1. 受保护的c端用户接口(C端用户登录后可访问) Url格式：/服务名称/my/资源名称/* 访问方式：需要携带C端用户认证所获取的Access Token才可访问。 2. 受保护的b端用户接口(B端管理员用户登录后可访问) Url格式：/服务名称/m/资源名称/* 访问方式：需要携带B端用户认证所获取的Access Token才可访问。 3. 公开资源 Url格式：/服务名称/资源名称/* 访问方式：无限制
以上匹配规则描述了：某个发往用户中心的请求，要想访问url匹配/my/**规则的资源，接入客户端需 要有scope中包含read，并且authorities(权限)中需要包含ROLE_CONSUMER，这跟 oauth_client_details表中的数据是相对应的。
1.4.3 功能实现 认证拦截功能主要由框架(Spring Security OAuth2)实现，我们无需处理。我们需要做的就是在过滤器 中把令牌中的用户信息取出来并转发给微服务使用。
@Component
public class AuthFilter extends ZuulFilter {
@Override
public boolean shouldFilter() {
return true;
}
public String filterType() {
return "pre"; //前置过滤器，可以在请求被路由之前调用
}
@Override
public int filterOrder() {
return 0;
}
@Override
public Object run() {
//1.获取Spring Security OAuth2的认证信息对象
Authentication authentication = SecurityContextHolder.getContext()
.getAuthentication();
if(authentication==null || !(authentication instanceof
OAuth2Authentication)){
return null;// 无token访问网关内资源，直接返回null
}
//2.将当前登录的用户以及接入客户端的信息放入Map中
OAuth2Authentication oauth2Authentication=
(OAuth2Authentication)authentication;
Map<String,String> jsonToken = new HashMap<>
(oauth2Authentication.getOAuth2Request().getRequestParameters());
/*3.将jsonToken写入转发微服务的request中*/
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
request.getParameterMap();// 关键步骤，一定要get一下，下面这行代码才能取到值
Map<String,List<String>> requestQueryParams =
ctx.getRequestQueryParams();
if (requestQueryParams == null) {
requestQueryParams = new HashMap<>();
}
List<String> arrayList = new ArrayList<>();
arrayList.add(EncryptUtil.encodeUTF8StringBase64(JSON.toJSONString(jsonToken)))
;
requestQueryParams.put("jsonToken", arrayList);
ctx.setRequestQueryParams(requestQueryParams);
return null;
}
}
/**
Token拦截处理
*/
public class TokenInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse, Object o)
{
String jsonToken = httpServletRequest.getParameter("jsonToken");
if (StringUtils.isNotBlank(jsonToken)) {
LoginUser loginUser = JSON
.parseObject(EncryptUtil.decodeUTF8StringBase64(jsonToken),
new TypeReference<LoginUser>() {
});
httpServletRequest.setAttribute("jsonToken", loginUser);
}
return true;
}
}
2 注册功能中的分布式事务
在用户注册流程中一次注册请求需要由用户中心服务和统一账号服务协调共同完成，由于种种原因，当 其中一个服务操作失败时会导致数据不一致，这样就产生了事务问题，本章节就要解决注册功能中的事 务问题。 请参考资料文件夹中的“分布式事务”，用户注册功能使用Hmily框架解决分布式事务问题。
3 用户开户
3.1 需求分析
开户是指借款用户和投资用户在注册后、交易前都需要在银行存管系统开通个人存管账户，在开户流程 中银行存管系统是一个很重要的系统，它是当前P2P平台最常见的一种模式，为了保证资金不流向P2P 平台，由银行存管系统去管理借款用户和投资用户的资金，P2P平台与银行存管系统进行接口交互为借 款用户和投资用户搭建交易的桥梁，它们之间的关系如下：
系统介绍： 存管系统：不属于P2P平台，属于银行系统，专门负责对接P2P账户及交易，此系统在银行部署， P2P平台的交易主要与存管系统交互。 存管代理服务：属于P2P平台，为了使P2P平台与银行存管系统松耦合，专门设立存管代理服务与 存管系统对接，P2P平台的各个服务都通过存管代理服务与银行存管系统交互。 开卡银行：不属于P2P平台，属于银行系统，是银行用于管理储蓄卡信息的系统。为了使用方便， 把该系统合并到了存管系统中。 由于存管系统属于银行，我们无需开发，直接提供
下面则是针对各个用例图说明的各个部分项目说明，
第一阶段：生成开户数据(图中1.1-1.8)
1、前端填写开户信息 前端会先查询开户信息，如果曾经填写了开户信息则在界面直接显示，用户可以修改; 如果曾经没有填 写开户信息则用户在界面填写开户信息
2、前端请求用户中心服务开户
3、用户中心服务准备开户数据，并把开户信息保存到用户中心
4、用户中心服务请求存管代理服务生成交易记录（未同步），并对开户数据进行签名
5、存管代理服务将签名后的开户数据返回给用户中心
6、用户中心将开户数据返回给前端
第二阶段：请求开户(图中2.1-2.8)
7、前端携带开户信息请求银行存管系统
8、银行存管系统向前端返回开户信息确定页面
9、前端确认完成提交开户请求到银行存管系统
10、银行存管系统接收开户数据并进行校验，校验银行卡信息，信息无误则将开户信息保存至存管系统 （校验过程中存管系统会请求开户银行校验银行卡信息）
第三阶段：开户结果通知(图中3.1-3.4)
11、开户成功后，银行存管系统异步通知存管代理服务
12、存管代理服务接收到开户成功通知后更新交易状态为同步
13、存管代理服务通知用户中心服务
14、用户中心服务接收到开户成功的消息保存开户信息