网站建设 前期资料江门网站推广深圳公司

当前位置： 首页 > news >正文

网站建设 前期资料,江门网站推广深圳公司,设计制作实践活动,许昌市建设局网站相关概念 认证与授权 认证#xff08;authentication #xff09;是验证你的身份的过程#xff0c;而授权#xff08;authorization#xff09;是验证你有权访问的过程 用户认证的逻辑 获取用户提交的用户名和密码根据用户名#xff0c;查询数据库#xff0c;获得完…相关概念 认证与授权 认证authentication 是验证你的身份的过程而授权authorization是验证你有权访问的过程 用户认证的逻辑 获取用户提交的用户名和密码根据用户名查询数据库获得完整的用户信息包括真正的密码比较提交的密码和查询到的密码如果二者相等则用户认证成功否则用户认证失败 密码加密 加密与解密 加密 数据加密 的基本过程就是对原来为 明文 的文件或数据按 某种算法 进行处理使其成为 不可读 的一段代码通常称为 “密文”。通过这样的途径来达到 保护数据 不被 非法人窃取、阅读的目的。 解密 加密 的 逆过程 为 解密即将该 编码信息 转化为其 原来数据 的过程。 加密算法 加密算法分 对称加密 和 非对称加密其中对称加密算法的加密与解密 密钥相同非对称加密算法的加密密钥与解密 密钥不同此外还有一类 不需要密钥 的 散列算法。 常见的 对称加密 算法主要有 DES、3DES、AES 等 常见的 非对称算法 主要有 RSA、DSA 等 散列算法 主要有 SHA-1、MD5 等。 对称加密 对称加密算法 是应用较早的加密算法又称为 共享密钥加密算法。在 对称加密算法 中使用的密钥只有一个发送 和 接收 双方都使用这个密钥对数据进行 加密 和 解密。这就要求加密和解密方事先都必须知道加密的密钥。 常见算法 数据加密过程在对称加密算法中数据发送方 将 明文 (原始数据) 和 加密密钥 一起经过特殊 加密处理生成复杂的 加密密文 进行发送。数据解密过程数据接收方 收到密文后若想读取原数据则需要使用 加密使用的密钥 及相同算法的 逆算法 对加密的密文进行解密才能使其恢复成 可读明文。 非对称加密 非对称加密算法又称为 公开密钥加密算法。它需要两个密钥一个称为 公开密钥 (public key)即 公钥另一个称为 私有密钥 (private key)即 私钥。 常见算法RSA 因为 加密 和 解密 使用的是两个不同的密钥所以这种算法称为 非对称加密算法。
如果使用 公钥 对数据 进行加密只有用对应的 私钥 才能 进行解密。如果使用 私钥 对数据 进行加密只有用对应的 公钥 才能 进行解密。 例子甲方生成 一对密钥 并将其中的一把作为 公钥 向其它人公开得到该公钥的 乙方 使用该密钥对机密信息 进行加密 后再发送给甲方甲方再使用自己保存的另一把 专用密钥 (私钥)对 加密 后的信息 进行解密。 比较 1 对称加密加密与解密使用的是同样的密钥所以速度快但由于需要将密钥在网络传输所以安全性不高。 2 非对称加密使用了一对密钥公钥与私钥所以安全性高但加密与解密速度慢。 3 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密然后发送出去接收方使用私钥进行解密得到对称加密的密钥然后双方可以使用对称加密来进行沟通。 散列算法 一类 不需要密钥 的 散列算法。 常见算法md5, 加盐 密码一般不会直接明文存储 会通过使用一定的算法例如md5进行加密存储 但是存在暴力破解的可能 解决方法最终密码其他盐值md5明文密码盐值 大大提高了安全性 盐值随机的一段字符串 密码加密——加盐算法两种方式_fiance111的博客-CSDN博客 协议 OAuth2 准备工作 | 微信开放文档 (qq.com) 用户登录状态的保存 HTTP 是一种不保存状态即无状态stateless协议。 cookie 将状态保存在客户端
客户端访问服务端的登录接口服务端根据请求的用户名和密码认证用户认证成功后向响应中写入Cookie //创建cookie
Cookie cookie new Cookie(islegal,yes);
//设置cookie的访问路径(哪些请求路径可以访问cookie)默认所有都可以访问
cookie.setPath(/project1/checkServlet);
//设置生命周期取值有三种://大于0单位是秒//等于0浏览器关闭//小于0-1 默认内存释放
cookie.setMaxAge(60*60);
resp.addCookie(cookie);3. 客户端接收响应并保存
用户再次请求的时候就会携带cookie 服务端如果可以访问cookie,则可以从中取出数据 Cookie[] cookies req.getCookies();
if(cookies!null){ for (Cookie cookie : cookies) { System.out.println(cookie.getName() cookie.getValue()); }
}tip: 如何修改cookie? 新创建cookie,只要路径和cookie的名称一致就可以修改cookie值 优缺点 session 基于服务端的状态保存 服务器会为每一次会话分配一个 Session对象同一个浏览器发起的多次请求,同属于一次会话( Session) 流程 首次使用到 Session时,服务器会自动创建 Session和JSeeisonID,并创建 Cookie用来存储 JSessionId发送回客户端, 下一次统一浏览器再次访问服务器的时候就会通过cookie携带JSessionId,来获取原来的Session 作用域 一次会话(可能有多次请求浏览器关闭会话结束)有效不同组件之间的session可以共享,java中有一块专门的内存保存session 钝化指关闭服务器后未关闭浏览器存储在session中的数据会通过序列化存储在磁盘上 活化指session中的数据被钝化过的浏览器未关闭服务器重新启动并将存储在磁盘上的数据读取到session中 session生命周期
//通过req获得session //有一个boolean参数默认true没有则会创建一个新的会话;false如果没有回话则不会创建 HttpSession session request.getSession();
System.out.println(session.getId());
//保存数据
session.setAttribute(name,gao);
//获取数据
String name (String)session.getAttribute(name);
//移除数据
session.removeAttribute(name);
//设置sesison的最大有效时间单位秒
session.setMaxInactiveInterval(60*60);
//手动销毁
session.invalidate(); 分布式 cookie 之前的方案都是在服务器端进行改造的cookie方案是客户端的方案就是把session信息保存到cookie中即用户信息保存到cookie中这样就不需要服务器保存session用户信息了。每次请求时把此cookie传给服务器端这样服务器端就知道是哪个用户了。 此方案比较实现比较简单而且还不占用服务器端的内存资源。但是此方案的问题很大哦。 1、cookie在客户端是有限的存储容量也是很小的 2、安全是很有问题的因为保存在本地很容易被人拿到 session复制 session复制是小型企业应用使用较多的一种服务器集群session管理机制在真正的开发使用的并不是很多通过对web服务器(例如Tomcat)进行搭建集群。 存在的问题 session同步的原理是在同一个局域网里面通过发送广播来异步同步session的一旦服务器多了并发上来了session需要同步的数据量就大了需要将其他服务器上的session全部同步到本服务器上会带来一定的网路开销在用户量特别大的时候会出现内存不足的情况 优点 服务器之间的session信息都是同步的任何一台服务器宕机的时候不会影响另外服务器中session的状态配置相对简单 Tomcat内部已经支持分布式架构开发管理机制可以对tomcat修改配置来支持session复制在集群中的几台服务器之间同步session对象使每台服务器上都保存了所有用户的session信息这样任何一台本机宕机都不会导致session数据的丢失而服务器使用session时也只需要在本机获取即可 session绑定黏贴 我们利用nginx的反向代理和负载均衡之前是客户端会被分配到其中一台服务器进行处理具体分配到哪台服务器进行处理还得看服务器的负载均衡算法(轮询、随机、ip-hash、权重等)但是我们可以基于nginx的ip-hash策略可以对客户端和服务器进行绑定同一个客户端就只能访问该服务器无论客户端发送多少次请求都被同一个服务器处理 缺点 容易造成单点故障如果有一台服务器宕机那么该台服务器上的session信息将会丢失前端不能有负载均衡如果有session绑定将会出问题 优点 配置简单 redis:session集中管理 优缺点 session优点 1.session中的信息存储在服务端相比于cookie就在一定程度上加大了数据的安全性。 2.session数据存储在服务端相比于jwt方便进行管理也就是说当用户登录和主动注销只需要添加删除对应的session就可以这样管理起来很方便。 session缺点 1.session存储在服务端这就增大了服务器的开销当用户多的情况下服务器性能会大大降低。 3、因为是基于cookie来进行用户识别的, cookie如果被截获用户就会很容易受到跨站请求伪造的攻击。 4、用户认证之后服务端做认证记录如果认证的记录被保存在内存中的话这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源这样在分布式的应用上相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。 token 客户端请求服务端登录服务端验证用户之后返回响应的时候生成一个token 常见生成token的方式就是JWT 客户端接收响应并保存token到localStor age或sessionStorage客户端下一次访问服务端的时候就通过Header携带token JWT JSON Web Tokens JWT 标准的 Token 有三个部分 1.header(头部)头部信息主要包括参数的类型–JWT,签名的算法–HS256 2.poyload(负荷)负荷基本就是自己想要存放的信息(因为信息会暴露不应该在载荷里面加入任何敏感的数据) 3.sign(签名)签名的作用就是为了防止恶意篡改数据 中间用点分隔开并且都会使用 Base64 编码所以真正的 Token 看起来像这样 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc Header Header 部分主要是两部分内容一个是 Token 的类型另一个是使用的算法比如下面类型就是 JWT使用的算法是 HS256。 {typ : JWT,alg : HS256 }上面的内容要用 Base64 的形式编码一下所以就变成这样 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9Payload Payload 里面是 Token 的具体内容这些内容里面有一些是标准字段你也可以添加其它需要的内容。下面是标准字段 issIssuer发行者 subSubject主题 audAudience观众 expExpiration time过期时间 nbfNot before iatIssued at发行时间 jtiJWT ID比如下面这个 Payload用到了 iss 发行人exp 过期时间另外还有两个自定义的字段一个是 name 还有一个是 admin 。 {iss : csdn.net,exp : 201511205211314,name : 维C果糖,admin : true }使用 Base64 编码以后就变成了这个样子 eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQSignature JWT 的最后一部分是 Signature 这部分内容有三个部分先是用 Base64 编码的 header 和 payload 再用加密算法加密一下加密的时候要放进去一个 Secret 这个相当于是一个密钥这个密钥秘密地存储在服务端。 header payload secret var encodedString base64UrlEncode(header) . base64UrlEncode(payload); HMACSHA256(encodedString, secret);处理完成以后看起来像这样 SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc客户端收到这个 Token 以后把它存储下来下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token 然后进行验证通过以后就会返回给客户端想要的资源。 服务端如何验证 和生成signature的方式一样然后比较signature是否一样 优缺点 不需要在服务端保存会话信息特别适用于分布式微服务。自包含(Self-contained):负载中包含了所有用户所需要的信息避免了多次查询数据库简洁(Compact):可以通过URL POST参数或者在HTTP header发送因为数据量小传输速度也很快因为Token是以JSON加密的形式保存在客户端的所以JWT是跨语言的原则上任何web形式都支持。 安全问题 CSRF 35.CSRF_哔哩哔哩_bilibili
当网站使用cookie保存用户登陆状态时可能受到恶意站点的诱导在不知道的情况下下向目标网站发起敏感请求 csrf保护就是当向目标网站发起敏感请求时要求携带csrf_token,这是一个客户端浏览器附带的伪随机数通过恶意站点发送的请求不会携带这个数据 springsecurity默认开启csrf保护对于put,post等方法不包含get),要求请求时携带csrf_token,前后分离项目本来就是使用token,不必开启csrf的保护 框架 Spring Security Spring SecuritySpring Security Community :: Spring Security Shrio 参考资料 认证 vs 授权 | Authing 文档Token的详细说明看这一篇就够了 - 简书 (jianshu.com)JSON Web Token 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)4种分布式session解决方案_断橋殘雪的博客-CSDN博客session-cookiejwt状态保持的差异以及优缺点_他们叫我浪浪的博客-CSDN博客浅谈常见的七种加密算法及实现 - 知乎 (zhihu.com)对称加密和非对称的加密 的优缺点和理解 - 知乎 (zhihu.com)密码加密——加盐算法两种方式_fiance111的博客-CSDN博客