20 使用Wrapper来解决一个头疼问题

68 阅读 0 评论 45 点赞

我是靠谱客的博主落寞裙子，最近开发中收集的这篇文章主要介绍20 使用Wrapper来解决一个头疼问题，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

问题是这样的, 现在有两个系统, 一个是与app交互的后台系统, session机制是自己写的, 使用sid的header作为认证的方式

另外一个后台系统, 此系统使用的session是服务器的session, 在某些场景下面需要调用前一个系统的一些接口

然后我当时思考这个问题的时候, 我以为第二个系统的sesion也是使用的自己写的session, 当时是有如下几种思路

前两种是比较简单的思路

1. 将系统一打包, 然后在系统二中重写需要调用系统一的接口, 重写controller层, 然后这样需要维护两个系统的controller层, 还是非常麻烦的

2. 两个系统共用一个session池, 那么系统二调用系统一的时候, 带上sid, 然后系统一不需要修改任何的东西, 此方法, 系统一, 二都不需要太大的改动, 但是这样吧两个系统的session耦合在一起了, 但是其实是比较适合于我们的场景的, 因为系统二能够登录的用户仅仅是系统一能够登录的用户的很少一部分

3. 在1的基础上面仅仅重写部分需要获取当前登录用户信息的接口, 放开不需要用户信息的接口[放掉拦截， public], 但是后来瞅了瞅, 调用的很多接口其实都使用了session中的数据, 因此差不多就是直接转换为了方法1, 而且安全性也不高, 此方法需要放开部分不需要用户信息的接口

4. 系统二在向系统一发送请求的时候, 带上自己的token信息, 然后然后系统一认证的时候, 增加一种认证方式, 然后认证之后, 为该用户录入系统一的session的信息, 然后之后系统二在访问系统一的时候, 带一个token, 然后拿到对应的session信息就行了, 此方法需要更新系统一的认证部分

这里我们讨论的重点是思路4, 看了上面的描述, 估计你会有一种懵逼的感觉, ok, 接来下来一张图

整个流程差不多是这样,, 前面的N个步骤都没有问题, 问题在于最后一个步骤, 拿到sid之后在request中增加sid的认证信息

我们都知道我们拿到request之后, 他的parameters, headers都是只读数据, 改不了, 然后提供给开发者使用的是一个atrributes的Map

然后这又怎么整呢 ..

我们需要一个sid头, 然后有没有,, 我突然想起了wrapper模式, 组合一下Request, 然后在获取sid头的时候, 返回我们拿到的sid不就行了么, 嘿嘿嘿

因为我的code没有传回来, 因此就直接写了一个

参考代码

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletRequestWrapper;

/**
* file name : VisitorRequest.java
* created at : 18:24 2017-03-04.
* created by 970655147 [970655147]
*/
public class VisitorRequest extends HttpServletRequestWrapper {

    // sid的key
    public String SID = "sid";

    // 拿到的sid
    private String sid;

    public VisitorRequest(String sid, HttpServletRequest request) {
        super(request);
        this.sid = sid;
    }

    @Override
    public String getHeader(String name) {
        if(SID.equals(name) ) {
            return sid;
        }

        return super.getHeader(name);
    }
}