java-security拦截时同时调用多个接口，其中随机部分接口校验不通过问题的定位和解决

最新推荐文章于 2024-05-21 14:51:14 发布

原创最新推荐文章于 2024-05-21 14:51:14 发布 · 1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#spring

技术同时被 2 个专栏收录

7 篇文章

订阅专栏

spring

3 篇文章

订阅专栏

前言：

又是普通的一天。最近在搞权限配置，用的是Spring security，token是用的jwt，通过服务中心签发token，业务层进行权限的配置。

问题：

权限这块配置上去了，发现在同时调用多个请求的时候，经常会有1到n个接口报错，报错显示是认证未通过。并且单个接口测试都没问题。

先说最终的问题原因：

由于每次作token校验的时候，会使用jjwt的parse方法进行解析，解析时需要传入rsa的公钥，而这公钥是需要每次进行临时写入系统文件之后再读取的，由于并发量高（也就几个），对同一文件的多个写入冲突了，导致获得公钥失败，从而导致解析失败。
以下是获得公钥的方法：

public static PublicKey getPublicKey() throws Exception {

        ClassPathResource resource = new ClassPathResource("rsa/rsa_public_key");
        // 临时目录
        String tempPath = System.getProperty("java.io.tmpdir") + System.currentTimeMillis() + ".rsa_public_key";
        File f = new File(tempPath);
        if (!f.exists()) {
            InputStream inputStream = null;
            try {
                inputStream = resource.getInputStream();
                IOUtils.copy(inputStream, new FileOutputStream(f));
                inputStream.close();
            } catch (IOException e) {
                System.out.println("fuckfuckfuck");
                e.printStackTrace();
            }
        }else{
            log.info("公钥已存在.公钥目录临时存储路径" + tempPath);
        }

        return getPublicKey(readFile(f));
    }

解决办法：

由于多次对同一文件进行写入，还得写入临时文件，效率还比较低，效率低就算了，还造成了这样的问题，索性改成创建静态变量维护byte[]，这样就解决了：

 private static byte[] PUBLIC_KEY;

    static {
        ClassPathResource resource = new ClassPathResource("rsa/rsa_public_key");
        // 临时目录
        String tempPath = System.getProperty("java.io.tmpdir") + ".rsa_public_key";
        File f = new File(tempPath);
        if (!f.exists()) {
            try {
                IOUtils.copy(resource.getInputStream(), new FileOutputStream(f));
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
        try {
            PUBLIC_KEY = readFile(f);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
     public static PublicKey getPublicKey() throws Exception {
        return getPublicKey(PUBLIC_KEY);
    }

问题的定位、解决过程

人生就像一场旅行不必在意目的地在乎的是沿途的风景和看风景的心情-利群

同理，相比与一个问题的解决，其实问题的定位、和解决的过程也是很重要的，它能够指导你下次碰到其他问题时也能自己去解决。（这也是为什么我们要不断总结、反思）我在这次走了很多弯路，一度认为自己没法解决了，于是请教同事，才找到了解决问题的路，跟着这条路走，问题果然解决了，那么接下来再走一遍这条路。

我们security里添加了两个filter，应对两种不同的token参数，而这个情况是在用户token的过滤时发生的，看下代码：

@Component
public class JwtAuthenticationTokenFilter extends OncePerRequestFilter {

    @Value("${jwt.header}")
    private String token_header;

    @Resource
    private JwtUtils jwtUtils;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {
        String auth_token = request.getHeader(this.token_header);
//        final String auth_token_start = "safept ";
//        if (StringUtils.isNotEmpty(auth_token) && auth_token.startsWith(auth_token_start)) {
//            auth_token = auth_token.substring(auth_token_start.length());
//        }
        if (StringUtils.isEmpty(auth_token)) {
            // 不按规范,不允许通过验证
            chain.doFilter(request, response);
//            auth_token = null;
            return;
        }

        String username = jwtUtils.getUsernameFromToken(auth_token);

        if (jwtUtils.containToken(username, auth_token) && username != null && SecurityContextHolder.getContext().getAuthentication() == null) {
            SysUser userDetail = jwtUtils.getUserFromToken(auth_token);
            RequestHolder.addUser(userDetail);
            if (jwtUtils.validateToken(auth_token, userDetail)) {
                UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetail, null, userDetail.getAuthorities());
                authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                logger.info(String.format("Authenticated userDetail %s, setting security context", username));
                SecurityContextHolder.getContext().setAuthentication(authentication);
            }
        }
        chain.doFilter(request, response);
    }
}

基于之前对security filter链的理解，可以知道，用户登陆认证失败，其实就是这边的authentication没有设置进去导致的，导致其没有set进去可能会是上面的三个判断失败导致：

 if (StringUtils.isEmpty(auth_token)) {
            // 不按规范,不允许通过验证
            chain.doFilter(request, response);
            return;
        }

token每次传入都正确，所以这边不会是原因。

剩下两个就是上面的两个if：

      if (jwtUtils.containToken(username, auth_token) && username != null && SecurityContextHolder.getContext().getAuthentication() == null) {

第三个判断条件不用看，就是当目前无authentication时再set，如果有的话，其实就是已经获得用户登陆认证了。

以及

if (jwtUtils.validateToken(auth_token, userDetail)) {

然后看里面的几个方法：

jwtUtils.containToken(username, auth_token)

  public boolean containToken(String userName, String token) {
        if (userName != null && tokenMap.containsKey(userName) && tokenMap.get(userName).equals(token)) {
            return true;
        }
        return false;
    }

之前维护了一个tokenMap存储用户信息，实际上是没有必要的。并且在负载均衡的情况下可能会出问题，果断把这玩意给去了。

username != null

String username = jwtUtils.getUsernameFromToken(auth_token);

public SysUser getUserFromToken(String token) {
        SysUser userDetail;
        try {
            final Claims claims = getClaimsFromToken(token);
            long userId = Long.parseLong(String.valueOf(claims.get(CLAIM_KEY_USER_ID)));
            String username = claims.getSubject();
            List<String> authNameList = (List<String>) claims.get(CLAIM_KEY_AUTHORITIES);
            List<SysAuth> auths = new ArrayList<>();
            for (String s : authNameList) {
                SysAuth auth = new SysAuth();
                auth.setName(s);
                auths.add(auth);
            }
            userDetail = new SysUser();
            userDetail.setAuths(auths);
           业务代码省略...
        } catch (Exception e) {
            userDetail = null;
        }
        return userDetail;
    }

再看关键的getClaimsFromToken方法：

private Claims getClaimsFromToken(String token) {
        Claims claims;
        try {
            claims = Jwts.parser()
                    .setSigningKey(getPublicKey())
                    .parseClaimsJws(token)
                    .getBody();
        } catch (Exception e) {
            e.printStackTrace();
            claims = null;
        }
        return claims;
    }

这边调用的是jjwt包里的parser方法，通过传入公钥进行token的签名认证，并获得body数据。看起来好像没什么问题，那么继续看getPublicKey（）方法：
上面也已经列过了，这里再列一遍

public static PublicKey getPublicKey() throws Exception {

        ClassPathResource resource = new ClassPathResource("rsa/rsa_public_key");
        // 临时目录
        String tempPath = System.getProperty("java.io.tmpdir") + System.currentTimeMillis() + ".rsa_public_key";
        File f = new File(tempPath);
        if (!f.exists()) {
            InputStream inputStream = null;
            try {
                inputStream = resource.getInputStream();
                IOUtils.copy(inputStream, new FileOutputStream(f));
                inputStream.close();
            } catch (IOException e) {
                System.out.println("fuckfuckfuck");
                e.printStackTrace();
            }
        }else{
            log.info("公钥已存在.公钥目录临时存储路径" + tempPath);
        }

        return getPublicKey(readFile(f));
    }

可以发现，它是写通过ClassPathResource获得相对路径下的公钥文件，然后写入系统文件里，最终通过readFile方法拿到由公钥转换成的byte[]，再调用getPublicKey方法，获得一个序列化的key。而这边的写入，可能就是线程不安全的！

别忘了validateToken方法：

 public Boolean validateToken(String token) {
//        final Date created = getCreatedDateFromToken(token);
        return (!isTokenExpired(token)
//                && !isCreatedBeforeLastPasswordReset(created, userDetail.getLastPasswordResetDate())
        );
    }

 private Boolean isTokenExpired(String token) {
        final Date expiration = getExpirationDateFromToken(token);
        return expiration.before(new Date());
    }

public Date getExpirationDateFromToken(String token) {
        Date expiration;
        try {
            final Claims claims = getClaimsFromToken(token);
            expiration = claims.getExpiration();
        } catch (Exception e) {
            expiration = null;
        }
        return expiration;
    }

代码很好理解，最终也是会调用getClaimsFromToken方法去解析token。所以问题的核心就是getPublicKey()方法的线程不安全性。找到症结了，就可以对症下药了，药方已在上面开出。