会话相关知识看过来

Cookie&Session&Token

HTTP服务是无状态的，为了解决无状态的这个问题出现了Cookie&Session&Token，三者都是用来维持客户端和服务端的会话的。

当客户端第一次访问服务端时，服务端会生成一个Session，自己保留一份称为session，给客户端返回一份，客户端将session保存在本地称为cookie，当客户端再次访问服务器时会自动的将cookie带着（有对应的携带规则），服务端会获取该cookie与自己保存的Session做对比验证，判断是否相同，如果相同则维持会话状态，否则不会维持该会话。

其实只有cookie和session就可以保持会话的连续，但它们是不安全的，有CSRF（跨站请求伪造攻击）风险，因此才有了Token的这种方式，token是服务器根据客户端的一些信息生成一个签名式的令牌，给到客户端，客户端保存在页面的隐藏域中或是本地，不以cookie的方式保存，这样就可以有效的防止CSRF。

CSRF攻击是你已经登录了某个网站，在本地保存了cookie，但你同时点开了一个恶意的网站，该网站内部有一个跨域请求访问你的网站，访问时会自动的带上cookie，因为你已经保存了cookie，所以这个恶意网站的访问也可以成功，这种方式称为CSRF。而token可以避免CSRF攻击是因为你的token并不以cookie的形式保存，即使恶意网站发起了请求，服务端的验证也不通过。只有你自己在提交时才会带着页面上或本地保存的token，这时到了服务器就可以验证成功。

同源策略&跨域

域名、协议、端口都会造成不同源。

浏览器的同源策略是一种安全功能，同源策略限制了从同一个源加载的文档或脚本与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。所以a.com下的js脚本采用ajax读取b.com里面的文件数据是会报错的。

限制的是ajax请求，一些标签<src/>、<script>、<iframe>的get请求和form表单的post请求是可以不受同源策略影响的，这也是实现跨域的方法，同时也是CSRF攻击的漏洞所在。

跨域实现方式

jsonp

此方法只能发起GET请求，利用<src/>、<script>、<iframe>标签。

cors

在浏览器中指定Origin来源，如果在服务器接受范围，请求则成功。

CORS与JSONP的使用目的相同，但是比JSONP更强大。 JSONP只支持GET请求，CORS支持所有类型的HTTP请求。

JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

对于cors方式的跨域 ，在浏览器端是透明的，我们只需要在服务器端做对应的设置即可

SSO 单点登录

SSO：Single Sign On，它把两个及以上个系统中的用户登录逻辑抽离出来，达到只输入一次用户名密码，就能实现同时登录多个系统的效果，有种通票的意思;

什么是单点登录

按照我们以往的经验，要想使用系统那么就得登录，但当一个企业有多个系统时，我们想反正都是同一个企业，我们可不可以实现，只要进行一次登录之后，不论我访问这个企业的哪个系统不需要登录就可以直接使用呢？这当然可以，这种实现就是单点登录，只需一次登录，就可以使用不同的系统（注意一般是一个企业相关的系统）。

实现方式

传统的验证登录是通过验证客户端的cookie与服务端的session来验证的，因此在我们进行不同系统访问时只需要让客户端在访问时带上它登录后服务端给它的cookie，以及服务端可以实现cookie和session的验证即可。

session共享

设置cookie的domain范围；
session共享，session不保存在服务器本地，而是保存在一个公共的地方，每次请求到来时服务器去该公共地点取得session去和cookie验证。

基于CAS的方式

CAS中心认证服务（Central Authentication Service）SSO 仅仅是一种架构，一种设计，而 CAS 则是实现 SSO 的一种手段。

前情：CAS中保持两个会话一个全局会话TGT 、一个局部会话session，浏览器与CAS服务器维持全局会话，与请求资源服务器维持局部会话。
浏览器与CAS:浏览器会在cookie中保存一个TGC（相当于sessionid）,用它可以找到TGT。
浏览器与起源服务器：cookie与session的原始方式。

请求的过程：浏览器访问A服务器，A服务器判断用户是否登录（通过局部会话session来判断），如果没登录将重定向请求到CAS服务器（重定向会携带浏览器请求自己的地址），CAS服务器首先判断是否与浏览器维持有会话（通过全局会话TGT来判断），如果没登录则返回登录界面给用户，用户进行相应的登录，登录成功后，CAS服务器会给用户一个令牌（ST）并将请求重定向到A服务器（这时CAS服务器会生成一个与该浏览器相关的TGT，而浏览器会保存在cookie中一个相对应的TGC），重定向到A服务器，A服务器拿到用户的令牌（ST）后会去CAS服务器验证真假（CAS服务器的TGC里保存有一些相关信息），验证通过给用户提供相应的服务，并与浏览器建立局部会话，否则拒绝。

当浏览器再次请求服务器A时，因为它与服务器A建立有局部会话，因此只要服务器A做校验就可以，无需再次重定向到CAS，而当用户访问加入单点登录的B服务器时，B服务器同样走A的流程，将请求转到CAS，这时因为浏览器与CAS保持有全局会话就无需做登录验证，CAS直接返回一个访问B的令牌（ST）并将请求重定向到B…

这就是CAS做单点登录的整个过程。

JWT

全名为Json Web token，它是一种基于JSON的令牌安全验证(在某些特定的场合可以替代Session或者Cookie)，一次生成随处校验；它将所有的会话信息都保存在客户端，服务器端通过对应的方式进行校验来满足会话式的服务过程。

组成

header.payload.signature  |  头.体.签名
头部信息表明用哪种签名算法 ，体信息我们可以自定义的保存一些用户权限相关信息，Signature 部分是对前两部分的签名，防止数据篡改，需要指定一个密钥（secret），这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），用header+payload+sectet原始数据生成签名的token。

校验

浏览器请求时将token带到服务器，服务器拿到该token取出header与payload部分，再加上自己保存的secret部分生成一次token，和传入的token做对比。

Shiro & Spirng Security

二者都是用于系统安全方面的安全框架。

Shiro 是 Java 的一个安全框架。目前，使用 Apache Shiro 的人越来越多，因为它相当简单，而 Spring Security是Spring提供的一个安全框架，相比之下Shiro可能没有 Spring Security 做的功能强大，但是在实际工作中我们可能并不需要那么复杂的东西，所以使用小而简单的Shiro 就足够了。

安全类框架提供的功可分为两大类：认证与授权。

认证：身份认证/登录，验证用户是不是拥有相应的身份，确定你是谁，什么身份；

授权：即权限验证，验证某个已认证的用户是否拥有某个权限，确定你的身份有无权限；

密码管理

密码是需要进行严格的保密的数据，一般情况下我们都会对密码进行一定的处理，采取特定的方式进行保存。
存储方式
1、明文
2、hash(明文)
3、hash(明文 + 盐)
盐
固定盐：在后台我们可以设定固定的盐来拼接到原始密码上，但这种方式会降低密码的安全性
随机盐：根据用户的一些其他信息（手机号、邮箱等）生成随机盐，或直接生成随机数作为随机盐，将随机盐保存在数据库中，当需要验证时取出做验证。
防破解
我们应该认识到一点无论我们怎么对数据进行加密，都不可能做到万无一失，我们只是提升破解的复杂度而已，一般情况下提升破解复杂度的方式有：
多重hash hash(明文 + 盐)、采用更加复杂的加密算法、引入风控系统（二次安全校验、异地登录、大额操作做进一步处理）

ant风格路径表达式