前言

  在前后端分离的项目中，前端调用后端接口时可能会遇到跨域问题，此时，我们脑袋中会冒出很多问号：

• 什么是跨域？
• 为什么会有跨域？
• 如何解决跨域？

  不要害怕，下面我们将解决他们。

序言

  在企业环境中，众多部门各自开发的认证系统，对用户来说，如果每个系统都需要独立登录，无疑增加了使用的复杂性。因此，如果有一把“万能钥匙”，能够让用户无需重复登录，直接访问每个系统，那将大大提升效率和用户体验。

  而本文要介绍的 SSO 就像一把万能钥匙，系统接入 SSO 后，用户只需登录一次，就可以访问所有系统，极大地简化了用户的操作步骤，提高了工作效率。

SSO 简介

  单点登录（ Single Sign-On , 简称 SSO ）是目前比较流行的服务于企业业务整合的解决方案之一， SSO 使得在多个应用系统中，用户只需要登录一次 就可以访问所有相互信任的应用系统。

体系架构

  在一个 SSO 系统里，一般会定义两类角色：

• Service Provider：简称SP ，登录信息的消费者，一般指Web应用。当用户访问 SP时，SP会检查用户是否已经登录。如果用户没有登录，SP 会将用户重定向到IDP 进行认证
• Identity Provider：简称 IDP，负责提供登录信息，甩于对用户进行认证，亦称认证中中心。当用户首次登录时，IDP会要求用户输入用户名秘密码。如果认证成功，IDP 会生成一个包含用户身份信息的凭证，并将用户重定向回 SP。SP 可以通过这个凭证来验证用户的身份

  如上图流程说明，SSO 实现模式一般包括以下三个原则：

• ① 所有的认证登录都在 SSO 认证中心进行；
• ② SSO 认证中心通过一些凭证来告诉 Web 应用当前访问用户究竟是不是已通过认证的用户；
• ③ SSO 认证中心和所有的 Web 应用建立一种信任关系，也就是说 web 应用必须信任认证中心

SSO 实现

  SSO 的实现一般有 CAS 和 OAuth2 两种：

  CAS 和 OAuth2 都可以用于实现 SSO，但它们的重点和实现方式略有不同。

  CAS 专注于提供统一登录服务，一般用于企业内部统一各个子系统的登录，而OAuth2 则更关注授权方面的问题，一般第三方系统统一外部登录。

Oauth2

  Oauth2 一般应用在各种社交应用的登录中，以 Google 为例，其交互流程如下：

1、访问 Client，Clilent 把用户redirect 到 Google（带着 SP 的信息）
2、用户登录Google（如果已登陆，这一步可以跳过）
3、Google 把用户redirect回Clilent（带着一个授权码code ）
4、Clilent 用这个授权码在后台向Google 换取 AccessToken，根据此 Token 可获取用户的信息（唯一ID、email之类的）
5、Clilent根据从Google获得的用户信息让用户继续使用。

CAS

  CAS 包括两部分：

• CAS Server：负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 / 密码等凭证
• CAS Client ：负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

流程步骤

  基础模式 SSO 访问流程主要有以下步骤：

• 访问服务： SSO 客户端发送请求访问应用系统提供的服务资源。
• 定向认证： SSO 客户端会重定向用户请求到 SSO 服务器。
• 用户认证：用户身份认证
• 发放票据： SSO 服务器会产生一个随机的 Service Ticket
• 验证票据： SSO 服务器验证票据 Service Ticket 的合法性，验证通过后，允许客户端访问服务
• 传输用户信息： SSO 服务器验证票据通过后，传输用户认证结果信息给客户端

简化流程

1.用户通过浏览器访问应用1，应用1发现用户没有登录，于是携带上一个service参数进行重定向，让用户去CAS Server上登录。
2.浏览器自动重定向到CAS Server上，CAS Server获取用户Cookie中携带的TGC， 去校验用户是否已经登录
a. 如果未登录，则重定向到CASServer的登录页面，用户输入用户名/密码，CAS
Server会生成票据TGT，并且根据TGT签发一个票据ST，再将TGC放在用户的Cookie中，完成身份校验
b.如果已经登录，则完成身份校验（此时CASServer可以根据用户的TGC找到TGT，进而获取用户的信息）
3.CASServer完成身份校验之后，会将ST拼接在service中，302重定向返回应用 1。此过程中浏览器将首先将TGC存在Cookie中，然后携带上ST重定向到应用1。4.应用1收到浏览器传来的S之后，拿去CASServer上校验，去判断用户的登录状态，如果用户登录合法，CAS Server就会返回用户信息给应用1。
5.浏览器再去访问应用2，应用2发现用户未登录，重定向到CASServer。
6.CASServer发现此时用户实际上已经登录了，于是又重定向回应用2，同时携带上ST。
7.应用2根据ST去CASServer上校验，获取用户的登录信息。

票据相关概念

  在CAS认证成功后，会生成三种类型的票据：

• TGT：全称Ticket Granting Ticket，相当于应用端的IttpSession，用户登录成功后，用户的基本信息，如用户名、登录有效期等信息，都将存储在此。
• TGC：全称Ticket Granting Cookie
  • TGC中存储了用于后续服务票据获取的凭证信息，以便用户在同一会话中访问多个服务而无需重新认证
  • TGC以Cookie的形式保存在浏览器中，通常主域名下，比如example.com。Cookip name为TGC，value为TGT，CAS Server可以根据TGC可以拿到TGT以确定对应用户
• ST：全称Service Ticket，ST是CAS Sever发放给用户的一张票据，用户在访问其他服务时，发现没有Cookie或者ST，那么就会302重定向到CAS Server获取ST，然后会携带着ST302重定向回来，CASC1ient则通过ST去CAS Server上获取用户的登录状态。之后子系统根据ST校验用户是否存在系统中，用户可以根据ST与CASServer交互获取用户信息，最后构建自己系统的权限信息，ST一次用完后，用户构建自己的用户信息，将不走Ticket拦截器

完整流程

  上图流程简单说明：

1. 用户通过浏览器访问应用1，应用1 发现用户没有登录，于是返回 302，并且携带上一个 service 参数，让用户去 CAS Server 上登录。
2. 浏览器自动重定向到 CAS Server 上，CAS Server 获取用户 Cookie 中携带的 TGC，去校验用户是否已经登录，如果已经登录，则完成身份校验（此时 CAS Server 可以根据用户的 TGC 找到 TGT，进而获取用户的信息）；如果未登录，则重定向到 CAS Server 的登录页面，用户输入用户名/密码，CAS Server 会生成 TGT，并且根据 TGT 签发一个 ST，再将 TGC 放在用户的 Cookie 中，完成身份校验。
3. CAS Server 完成身份校验之后，会将 ST 拼接在 service 中，返回 302，浏览器将首先将 TGC 存在 Cookie 中，然后根据 302 的指示，携带上 ST 重定向到应用1。
4. 应用1 收到浏览器传来的 ST 之后，拿去 CAS Server 上校验，去判断用户的登录状态，如果用户登录合法，CAS Server 就会返回用户信息给 应用1。
5. 浏览器再去访问应用2，应用2 发现用户未登录，重定向到 CAS Server。
6. CAS Server 发现此时用户实际上已经登录了，于是又重定向回应用2，同时携带上 ST。
7. 应用2 拿着 ST 去 CAS Server 上校验，获取用户的登录信息。

在整个登录过程中，浏览器分别和 CAS Server、应用1、应用2 建立了会话，其中，和 CAS Server 建立的会话称之为全局会话，和应用1、应用2 建立的会话称之为局部会话；一旦局部会话成功建立，以后用户再去访问应用1、应用2 就不会经过 CAS Server 了。

其他流程图

CAS 安全

  CAS 的安全性仅仅依赖于 SSL 。使用的是 secure cookie 。

TGC 安全

  对于一个 CAS 用户来说，最重要是要保护它的 TGC ，如果 TGC 不慎被 CAS Server 以外的实体获得， Hacker 能够找到该 TGC ，然后冒充 CAS 用户访问 所有 授权资源。 PGT 的角色跟 TGC 是一样的。

  从基础模式可以看出， TGC 是 CAS Server 通过 SSL 方式发送给终端用户，因此，要截取 TGC 难度非常大，从而确保 CAS 的安全性。

  TGT 的存活周期默认为 120 分钟。

ST 安全性

  ST （ Service Ticket ）是通过 Http 传送的，因此网络中的其他人可以 Sniffer 到其他人的 Ticket 。 CAS 通过以下几方面来使 ST 变得更加安全（事实上都是可以配置的）：

• ST 只能使用一次：CAS 协议规定，无论 Service Ticket 验证是否成功， CAS Server 都会清除服务端缓存中的该Ticket ，从而可以确保一个 Service Ticket 不被使用两次。
• ST 在一段时间内失效：CAS 规定 ST 只能存活一定的时间，然后 CAS Server 会让它失效。默认有效时间为 5 分钟。
• ST 基于随机数生成：ST 必须足够随机，如果 ST 生成规则被猜出， Hacker 就等于绕过 CAS 认证，直接访问对应的服务，因此 ST 是基于随机数生成的

重构中

前言

  由于现在大多数公司安全认证基本都使用的是 Token 方式，而以前却没怎么接触过，因此系统性的了解了一下相关历史，并小小的总结了一下。
  对互联网目前的安全认证机制，大概主要分为以下三种方式：

• HTTP Basic Auth
• Cookie Based Auth
• Token Based Auth

  那么，它们各自的定义是什么，对应的认证流程又是怎样的，各自又有什么样的特点呢？
  跟随本文来了解一下吧！

  在 Vue 项目中，若想通过网络去请求一些数据，就需要使用 Axios 啦。

什么是 Vuex?

  Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。

  Vuex 采用集中式存储管理应用的所有组件的状态，并以相应的规则保证状态以一种可预测的方式发生变化。

序言

  当客户端发出一些对微服务获取资源的请求到后端，这些请求将通过 FS、 Nginx 等设施的路由和负载均衡分配并转发到各个不同的服务实例上。为了让这些设施能够正确路由与分发请求，运维人员需要手工维护这些路由规则与服务实例列表， 当有实例增减或是 IP 地址变动等情况发生的时候，也需要手工地去同步修改这些信息以保持实例信息与中间件的一致。当系统规模不断增大时，这些看似简单的维护任务会变得越来越麻烦，且配置出错概率也会增加。

  很显然，上述做法并不可取，因此，我们需要一套机制来有效降低维护路由规则与服务实例列表的难度。

  对于某些服务的权限校验（如用户登录状态的校验），若突然发现校验逻辑有个 BUG 需要修复，或者需要对其做一些扩展和优化，此时就不得不去每个应用里修改这些逻辑，这样的修改不仅会引起开发入员的抱怨，更会加重测试人员的负担。所以，我们也需要一套机制，能够很好地解决微服务架构中，对于微服务接口访问时各前置校验的冗余问题。

  这时候就可以使用 API 网关，Gateway 就是一种网关。

  由于后起之秀 Gateway 的诞生，不建议在新项目中再使用 Zuul。

序言

  当客户端发出一些对微服务获取资源的请求到后端，这些请求将通过 FS、 Nginx 等设施的路由和负载均衡分配并转发到各个不同的服务实例上。为了让这些设施能够正确路由与分发请求，运维人员需要手工维护这些路由规则与服务实例列表， 当有实例增减或是 IP 地址变动等情况发生的时候，也需要手工地去同步修改这些信息以保持实例信息与中间件的一致。当系统规模不断增大时，这些看似简单的维护任务会变得越来越麻烦，且配置出错概率也会增加。

  很显然，上述做法并不可取，因此，我们需要一套机制来有效降低维护路由规则与服务实例列表的难度。

  对于某些服务的权限校验（如用户登录状态的校验），若突然发现校验逻辑有个 BUG 需要修复，或者需要对其做一些扩展和优化，此时就不得不去每个应用里修改这些逻辑，这样的修改不仅会引起开发入员的抱怨，更会加重测试人员的负担。所以，我们也需要一套机制，能够很好地解决微服务架构中，对于微服务接口访问时各前置校验的冗余问题。

  这时候就可以使用 API 网关，Zuul 就是一种网关。

序言

  在前面的例子中，我们使用了 Ribbon 的负载均衡功能，大大优化了远程调用时的代码：

1
2

String url = "http://user-service/user/" + id;
return restTemplate.getForObject(url, String.class);

  但是，我们以后可能需要编写类似的重复代码，格式基本相同，无非参数不一样，有没有更优雅的方式来对这些代码再次优化呢？
  而且，我们使用了 Hystrix 的熔断功能，但将熔断的方法直接嵌套在业务代码中间，会不会显得有些杂乱？这一点又能不能优化呢？
  当然可以，Feign 对 Ribbon 和 Hystrix 都进行了封装，上面 2 个都是小 case 。

  Feign 基于 Netflix Feign 实现，它整合了 Ribbon 与 Hystrix ， 除了提供这两者的强大功能之外，它还提供了一种声明式的 Web 服务客户端定义方式。

  由于后起之秀 Sentinel 的诞生，不建议在新项目中再使用 Hystrix。

序言

  在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。

  为了解决这样的问题， 产生了熔断器等一系列的服务保护机制。

  在分布式架构中， 断路器模式的作用也是类似的，当某个服务单元发生故障（类似电器发生短路） 之后， 通过熔断器的故障监控（类似熔断保险丝）， 向调用方返回一个错误响应， 而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

  Hystrix 就是一种熔断器，具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能.。

序言

  在微服务项目中，我们肯定会部署服务集群以防故障发生，那么，如何保证请求的每台服务器受到的压力都差不多呢？

  答案是通过负载均衡进行实现。

  Ribbon 就是实现负载均衡的工具之一。