Spring Security

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 类加载过程 Class 文件需要加载到虚拟机中之后才能运行和使用，那么虚拟机是如何加载这些 Class 文件呢？ 系统加载 Class 类型的文件主要三步: 加载->连接->初始化 。连接过程又可分为三步: 验证->准备->解析 。 加载 类加载过程的第一步，主要完成下面3件事情： 通过全类名获取定义此类的二进制字节流 将字节流所代表的静态存储结构转换为方法区的运行时数据结构 在内存中生成一个代表该类的 Class 对象,作为方法区这些数据的访问入口 虚拟机规范多上面这3点并不具体，因此是非常灵活的。比如："通过全类名获取定义此类的二进制字节流" 并没有指明具体从哪里获取、怎样获取。比如：比较常见的就是从 ZIP 包中读取（日后出现的JAR、EAR、WAR格式的基础）、其他文件生成（典型应用就是JSP）等等。 一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的 loadClass() 方法）。数组类型不通过类加载器创建，它由 Java 虚拟机直接创建。 类加载器、双亲委派模型也是非常重要的知识点，这部分内容会在后面的文章中单独介绍到。 加载阶段和连接阶段的部分内容是交叉进行的，加载阶段尚未结束

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 在WebFlux的注解模式下没有找到有用的直接从 ServerHttpRequest 读取请求报文流的方法，下面是我自己摸索出来的方法，主要借鉴了Spring Security的源码， 重点是需要注入 Webflux的解码器 @Autowired private ServerCodecConfigurer serverCodecConfigurer = null; 然后在进行如下处理: @PostMapping("/connect") public Mono<Void> connect(final ServerHttpRequest request, final ServerHttpResponse response) { log.debug("connect..."); final ResolvableType reqDataType = ResolvableType.forClass(byte[].class); return response.writeWith(serverCodecConfigurer.getReaders().stream() .filter(reader -> reader.canRead(reqDataType, MediaType.ALL)) .findFirst()

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1 pom.的主要文件 我引入的thymeleaf-extras-springsecurity5，springboot2.1.6 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <!-- https://mvnrepository.com/artifact/org.thymeleaf.extras/thymeleaf-extras-springsecurity4 --> <dependency> <groupId>org.thymeleaf.extras</groupId> <artifactId>thymeleaf-extras-springsecurity5</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency>

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> rbac-security GitHub地址 这是一个基于简单的RBAC模型，结合Spring Security开发的权限管理模块。 一、RBAC模型介绍 RBAC是Role-Based Access Control的缩写，意思就是基于角色的权限访问控制。 基本思想： 对系统的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。 同样用户被分配了多个适当的角色，那么该用户就拥有了被分配多个角色的所有权限。 优点： 不必在每次创建用户时都进行分配权限的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，这样将 简化 用户的权限管理，减少系统的开销。 该系统的RBAC模型—— 二、项目思想 本项目将对用户、角色、权限三者之间的关联状态概念交给系统管理员与数据库，对外依然具有RBAC的概念。但是在项目的权限管理中，项目只维护用户与权限的关系。 当用户登录成功后立即在数据库查询该用户所具有的角色，再根据所拥有的角色查询对应的权限——然后将这些权限赋予用户。 该项目的所有接口都是基于权限级别的身份校验，而非角色级别的身份校验。 优点： 节省了对用户与角色

SpringCloud（第 031 篇）配置客户端ConfigClient链接经过对称加解密的配置微服务 一、大致介绍 1、Git服务端的文件内容进行了加密处理，那么是不是配置客户端拿到内容之后需要解密呢？ 2、答案显然不是的，因为这样解密的话，先不说实现起来的难易程度，单从表面上来讲，若是加解密频繁换的话，那客户端是不是每次都得升级解密算法呢？ 3、而 SpringCloud 配置客户端不需要做什么加解密的配置，加解密的配置在服务端做就好了； 4、这里还顺便列举下配置路径的规则： /**************************************************************************************** * 配置服务的路劲规则： * * /{application}/{profile}[/{label}] * /{application}-{profile}.yml * /{label}/{application}-{profile}.yml * /{application}-{profile}.properties * /{label}/{application}-{profile}.properties ************************************************************

1. 前言 上一文 我们对Spring Security中的重要用户信息主体 UserDetails 进行了探讨。中间例子我们使用了明文密码，规则是通过对密码明文添加 {noop} 前缀。那么本节将对 Spring Security 中的密码编码进行一些探讨。 2. 不推荐使用md5 首先 md5 不是加密算法，是哈希摘要。以前通常使用其作为密码哈希来保护密码。由于彩虹表的出现， md5 和 sha1 之类的摘要算法都已经不安全了。如果有不相信的同学 可以到一些解密网站 如 cmd5 网站尝试解密 你会发现 md5 和 sha1 是真的非常容易被破解。 3. Spring Security中的密码算法 上一文用户主体 我们提到了 InMemoryUserDetailsManager 初始化Bean 需要传输一个 ObjectProvider<PasswordEncoder> 参数。这里的 PasswordEncoder 就是我们对密码进行编码的工具接口。该接口只有两个功能： 一个是匹配验证。另一个是密码编码。 上图就是Spring Security 提供的 org.springframework.security.crypto.password.PasswordEncoder 一些实现，有的已经过时。其中我们注意到一个叫 委托密码编码器的实现 。 3.1 委托密码编码器

一、什么是CSRF 很多朋友在学习Spring Security的时候，会将CORS(跨站资源共享)和CSRF(跨站请求伪造)弄混，以为二者是一回事。其实不是，先解释一下： CORS(跨站资源共享)是局部打破同源策略的限制，使在一定规则下HTTP请求可以突破浏览器限制，实现跨站访问。 CSRF是一种网络攻击方式，也可以说是一种安全漏洞，这种安全漏洞在web开发中广泛存在。 当我们使用Spring Security的时候，这种CSRF漏洞默认的被防御掉了。但是你会发现在跨域请求的情况下，我们的POST、DELETE、PUT等HTTP请求方式失效了。所以在笔者之前的文章中，我们使用 http.csrf.disable() 暂时关闭掉了CSRF的防御功能，但是这样是不安全的，那么怎么样才是正确的做法呢？就是本文需要向大家介绍的内容。 二、CSRF的攻击方式 通常的CSRF攻击方式如下： 你登录了网站A，攻击者向你的网站A账户发送留言、伪造嵌入页面，带有危险操作链接。 当你在登录状态下点击了攻击者的连接，因此该链接对你网站A的账户进行了操作。 这个操作是你在网站A中主动发出的，并且也是针对网站A的HTTP链接请求，同源策略无法限制该请求。 三、如何防御CSRF攻击 为系统中的每一个连接请求加上一个token，这个token是随机的，服务端对该token进行验证

Spring-security-oauth2的版本是2.2.3。 RemoteTokenServices是用于向远程认证服务器验证token，同时获取token对应的用户的信息。 图1 RemoteTokenServices会通过RestTemplate调用远程服务，我们在使用这个类时，要设置checkTokenEndpointUrl、clientId、clientSecret等。 RemoteTokenServices的源码如下， List-1 public class RemoteTokenServices implements ResourceServerTokenServices { protected final Log logger = LogFactory.getLog(this.getClass()); private RestOperations restTemplate = new RestTemplate(); private String checkTokenEndpointUrl; private String clientId; private String clientSecret; private String tokenName = "token"; private AccessTokenConverter tokenConverter = new

这篇是继 上一篇 之后的。 当我们访问/oauth/token时，首先会经过BasicAuthenticationFilter，之后才会到TokenEndPoint 图1 org.springframework.security.web.authentication.www.BasicAuthenticationFilter的doFilter调用doFilterInternal，如下List-1所示，会从头部取出Authorization字段，由authenticationManager来处理。 List-1 protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws IOException, ServletException { boolean debug = this.logger.isDebugEnabled(); String header = request.getHeader("Authorization"); if (header != null && header.startsWith("Basic ")) { try { String[] tokens = this

Spring-security-oauth2的版本是2.2.0。 首先来看类的继承图，如下图１所示 图1 有注解FrameworkEndpoint，这个注解和Spring的Controller注解一样的，只是这个FrameworkEndpoint注解是给框架用的，它有处理/oauth/token的方法，分别对应get和post的请求，如下图2所示 图2 图2中postAccessToken的处理流程如下图3所示，流程很长，这一切都是为了生成Token，保存Token到TokenStore，之后返回Token。 图3 当我们为了得到Token，去访问/oauth/token的时候，处理的流程如上图3所示 Reference https://www.jianshu.com/p/62dd1e4664ee 来源： oschina 链接： https://my.oschina.net/u/2518341/blog/3014166