前面和大家聊了 Spring Security 如何像 QQ 一样，自动踢掉已登录用户（Spring Boot + Vue 前后端分离项目，如何踢掉已登录用户？），但是前面我们是基于单体应用的，如果我们的项目是集群化部署，这个问题该如何解决呢？

前两天和大家聊了 Spring Security 中的 session 并发问题，和小伙伴们聊了如何像 QQ 一样，用户在一台设备上登录成功之后，就会自动踢掉另一台设备上的登录。

[TOC]

之前有小伙伴表示，看 Spring Security 这么麻烦，不如自己写一个 Filter 拦截请求，简单实用。

[TOC]

关于文件上传这块，松哥之前也写了好几篇文章了，甚至还有视频：

上篇文章中，我们讲了在 Spring Security 中如何踢掉前一个登录用户，或者禁止用户二次登录，通过一个简单的案例，实现了我们想要的效果。

但是有一个不太完美的地方，就是我们的用户是配置在内存中的用户，我们没有将用户放到数据库中去。正常情况下，松哥在 Spring Security 系列中讲的其他配置，大家只需要参考Spring Security+Spring Data Jpa 强强联手，安全管理只有更简单！一文，将数据切换为数据库中的数据即可。

登录成功后，自动踢掉前一个登录用户，松哥第一次见到这个功能，就是在扣扣里边见到的，当时觉得挺好玩的。

自己做开发后，也遇到过一模一样的需求，正好最近的 Spring Security 系列正在连载，就结合 Spring Security 来和大家聊一聊这个功能如何实现。

上篇文章跟大家聊了如何使用更加优雅的方式自定义 Spring Security 登录逻辑，更加优雅的方式可以有效避免掉自定义过滤器带来的低效，建议大家一定阅读一下，也可以顺便理解 Spring Security 中的认证逻辑。

本文将在上文的基础上，继续和大家探讨如何存储登录用户详细信息的问题。

有小伙伴会说，自定义认证逻辑还不简单？是的，没错，松哥之前也多次教过大家如何自定义认证逻辑，无论是添加登录验证码还是修改登录数据库格式，都需要对认证逻辑作出调整。

之前我们自定义的一个核心思路就是自定义过滤器，在过滤器中做各种各样我们想做的事：

最近松哥一直在和大家介绍 Spring Security 以及 OAuth2 相关的技能点，连载的文章也写了好多篇了，大家在公众号后台回复 2020 可以获取原创文章索引。

在上篇文章中，我们提到了 Spring Boot 自动登录存在的一些安全风险，在实际应用中，我们肯定要把这些安全风险降到最低，今天就来和大家聊一聊如何降低安全风险的问题。