Spring Security

1. 前言 Spring Security 实战干货：内置 Filter 全解析 中提到的第 32 个 Filter 不知道你是否有印象。它决定了访问特定路径应该具备的权限，访问的用户的角色，权限是什么？访问的路径需要什么样的角色和权限？ 它就是 FilterSecurityInterceptor ，正是我们需要的那个轮子。 2.FilterSecurityInterceptor 过滤器排行榜第 32 位！肩负对 http 接口权限认证的重要职责。我们来看它的过滤逻辑： public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { FilterInvocation fi = new FilterInvocation(request, response, chain); invoke(fi); } 初始化了一个 FilterInvocation 然后被 invoke 方法处理： public void invoke(FilterInvocation fi) throws IOException, ServletException { if ((fi.getRequest() != null)

ApiBoot Security 内部提供了 两种方式 进行读取需要认证的用户信息，在之前的文章中讲到过 ApiBoot Security 使用 内存方式（memory） 不写一行代码 就可以实现用户的认证并获取 AccessToken ，那我们使用 JDBC 方式是不是也是这么的简单呢？ 如果你还对 ApiBoot 不了解，可以通过以下的途径来获取帮助。 官方文档： http://apiboot.minbox.io 源码： https://gitee.com/minbox-projects/api-boot ApiBoot Security的认证方式 有一些同学可能对 ApiBoot Security 的两种认证方式还不太了解，下面介绍下这两种认证方式的区别。 内存方式 内存方式（memory） 是将用户信息（用户名、密码、角色列表）在 application.yml 文件内配置，可配置多个用户，项目启动后将用户信息加载到内存中，用于获取 AccessToken 时的认证。 数据库方式 数据库方式（jdbc） 是将用户信息保存到数据库内， ApiBoot Security 定义了一个默认表结构的 用户信息数据表 ，我们可以从官网找到 建表语句 直接在自己的数据库内创建即可，当然如果不使用默认的表结构可以进行自定义读取用户信息。 注意：在数据库内存放用户的 密码 必须是通过

第一章 Spring 介绍 1.1 什么是 Spring 1.1.1 Spring 框架的演变 1.1.2 反转控制或依赖注入 1.1.3 依赖注入的演变 1.1.4 除了依赖注入 1.2 Spring 项目 1.2.1 Spring 的起源 1.2.2 Spring 社区 1.2.3 Spring 工具套件 1.2.4 Spring Security 项目 1.2.5 Spring Boot 1.2.6 Spring 批处理和集成 1.2.7 许多其他项目 1.3 Spring 的替代品 1.3.1 JBoss Seam 框架 1.3.2 Google Guice 1.3.3 PicoContainer 1.3.4 JEE 7 部署 1.4 小结 来源： https://my.oschina.net/beborn/blog/3135165

在上一次写的文章中，为大家说到了如何动态的从数据库加载用户、角色、权限信息，从而实现登录验证及授权。在实际的开发过程中，我们通常会有这样的一个需求：当用户多次登录失败的时候，我们应该将账户锁定，等待一定的时间之后才能再次进行登录操作。 一、基础知识回顾 要实现多次登录失败账户锁定的功能，我们需要先回顾一下基础知识： Spring Security 不需要我们自己实现登录验证逻辑，而是将用户、角色、权限信息以实现UserDetails和UserDetailsService接口的方式告知Spring Security。具体的登录验证逻辑Spring Security 会帮助我们实现。 UserDetails接口中有一个方法叫做isAccountNonLocked()用于判断账号是否被锁定，也就是说我们应该通过该方法对应的set方法setAccountNonLocked(false)告知Spring Security该登录账户被锁定。 那么应该在哪里判断账号登录失败的次数并执行锁定机制呢？当然是我们之前文章给大家介绍的《自定义登录成功及失败结果处理》的AuthenticationFailureHandler。 建议您先阅读本文，如果您对本文的实现过程感到迷惑，建议您再翻看本号之前的相关内容。 二、实现多次登录失败锁定的原理 一般来说实现这个需求

1.前言 JSON Web Token (JWT) 其实目前已经广为软件开发者所熟知了，但是 JOSE (Javascript Object Signing and Encryption) 却鲜有人知道，我第一次知道它是在 Spring Security 的官方文档中，它改变了我对 JWT 的一些认识。目前国内能找到相关中文资料不是太多。所以我觉得有必要归纳一下。 2. JOSE 概述 JOSE 是一种旨在提供在各方之间安全传递声明（claims）的方法的规范集。我们常用的 JWT 就包含了允许客户端访问特定应用下特定资源的声明。 JOSE 制定了一系列的规范来达到此目的。目前该规范还在不断的发展，我们常用的包含以下几个 RFC : JWS（RFC 7515） -JSON Web签名，描述生成和处理签名消息 JWE（RFC 7516） -JSON Web加密，描述了保护和处理加密 消息 JWK（RFC 7517） -JSON Web密钥，描述 Javascript 对象签名和加密中加密密钥的 格式和处理 JWA（RFC 7518） -JSON Web算法，描述了 Javascript 对象签名和加密中使用的 加密 算法 JWT（RFC 7519） -JSON Web令牌，描述以 JSON 编码并由 JWS 或 JWE 保护的声明的表示形式 3. 我们都看错了 JWT 看了对 JWT

1.前言 JSON Web Token (JWT) 其实目前已经广为软件开发者所熟知了，但是 JOSE (Javascript Object Signing and Encryption) 却鲜有人知道，我第一次知道它是在 Spring Security 的官方文档中，它改变了我对 JWT 的一些认识。目前国内能找到相关中文资料不是太多。所以我觉得有必要归纳一下。 2. JOSE 概述 JOSE 是一种旨在提供在各方之间安全传递声明（claims）的方法的规范集。我们常用的 JWT 就包含了允许客户端访问特定应用下特定资源的声明。 JOSE 制定了一系列的规范来达到此目的。目前该规范还在不断的发展，我们常用的包含以下几个 RFC : JWS（RFC 7515） -JSON Web签名，描述生成和处理签名消息 JWE（RFC 7516） -JSON Web加密，描述了保护和处理加密 消息 JWK（RFC 7517） -JSON Web密钥，描述 Javascript 对象签名和加密中加密密钥的 格式和处理 JWA（RFC 7518） -JSON Web算法，描述了 Javascript 对象签名和加密中使用的 加密 算法 JWT（RFC 7519） -JSON Web令牌，描述以 JSON 编码并由 JWS 或 JWE 保护的声明的表示形式 3. 我们都看错了 JWT 看了对 JWT

很多人觉得Spring Security实现登录验证很难，我最开始学习的时候也这样觉得。因为我好久都没看懂我该怎么样将自己写的用于接收用户名密码的Controller与Spring Security结合使用，这是一个先入为主的误区。后来我搞懂了：根本不用你自己去写Controller。你只需要告诉Spring Security用户信息、角色信息、权限信息、登录页是什么？登陆成功页是什么？或者其他有关登录的一切信息。具体的登录验证逻辑它来帮你实现。 一、动态数据登录验证的基础知识 在本号之前的文章中，已经介绍了Spring Security的formLogin登录认证模式，RBAC的权限控制管理模型，并且针对Spring Security的登录认证逻辑源码进行了解析等等。我们所有的用户、角色、权限信息都是在配置文件里面写死的，然而在实际的业务系统中，这些信息通常是存放在RBAC权限模型的数据库表中的。下面我们来回顾一下其中的核心概念： RBAC的权限模型可以从用户获取为用户分配的一个或多个角色，从用户的角色又可以获取该角色的多种权限。通过关联查询可以获取某个用户的角色信息和权限信息。 在源码解析的文章中，我们知道如果我们不希望用户、角色、权限信息写死在配置里面。我们应该实现UserDetails与UserDetailsService接口，从而从数据库或者其他的存储上动态的加载这些信息

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类，它们之间的依赖，构建起了整个框架。想要理解整个架构，最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder 用于存储安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权限…这些都被保存在SecurityContextHolder中。 SecurityContextHolder 默认使用 ThreadLocal 策略来存储认证信息。看到 ThreadLocal 也就意味着，这是一种与线程绑定的策略。Spring Security在用户登录时自动绑定认证信息到当前线程，在用户退出时，自动清除当前线程的认证信息。但这一切的前提，是你在web场景下使用Spring Security，而如果是Swing界面，Spring也提供了支持， SecurityContextHolder 的策略则需要被替换，鉴于我的初衷是基于web来介绍Spring Security，所以这里以及后续，非web的相关的内容都一笔带过。 获取当前用户的信息 因为身份信息是与线程绑定的，所以可以在程序的任何地方使用静态方法获取用户信息。一个典型的获取当前登录用户的姓名的例子如下所示： Object

实现的目的是 对普通用户和管理员的登录接口 分别进行拦截。其他的不做处理。该配置适用于 springboot package cn.exrick.xboot.config.security; import cn.exrick.xboot.common.utils.SecurityUtil; import cn.exrick.xboot.config.properties.IgnoredUrlsProperties; import cn.exrick.xboot.config.properties.XbootTokenProperties; import cn.exrick.xboot.config.security.jwt.AuthenticationFailHandler; import cn.exrick.xboot.config.security.jwt.AuthenticationSuccessHandler; import cn.exrick.xboot.config.security.jwt.JWTAuthenticationFilter; import cn.exrick.xboot.config.security.jwt.RestAccessDeniedHandler; import cn.exrick.xboot.config.security

一、CORS简述 要说明CORS(Cross Origin Resourse-Sharing) 跨站资源共享，就必须先说同源策略。长话短说，同源策略就是向服务端发起请求的时候，以下三项必须与当前浏览器应用一致：域名、端口、协议。用白话说：就是你的应用发送请求不能访问别人的资源，否则浏览器就会限制你。当然也有例外，如：img、srcipt、iframe等资源引用的HTML标签不受同源策略的限制。 但是我们实际开发中又经常会跨站访问，比如前后端分离的应用是分开部署的，在浏览器看来是两个域。所以同源策略是用来禁止跨域访问的，CORS正好相反是根据自己的需求与规则，有限的开放部分资源的共享。 二、Spring-CORS规则基础配置 想在Spring或Spring Boot的web环境下实现跨域资源共享，主要有三种实现方式： @CrossOrigin注解，这个注解是作用于Controller类或者请求方法上的，实现局部接口的跨域资源共享。 实现WebMvcConfigurer接口addCorsMappings方法，实现全局配置的跨域资源共享。 注入CorsFilter过滤器，实现全局配置的跨域资源共享。推荐使用。 这三种实现方式在我的另外一篇文章 《SpringBoot解决跨域访问的问题》 中已经介绍过，这里就不多做说明了。 三、Spring Security 中的配置CORS