余思博客

简介Dart语言诞生于2011年10月10日，由谷歌主导开发的开源语言，Dart是一种“结构化的Web编程”语言，可以在所有现代浏览器和环境中提供高性能。Dart语言可用于Web、服务器、移动应用和物联网等领域的开发。 Dart语言目前最新版本是2.17.6，目前可用于全平台的开发，注意Dart也是一门面向对象的编程语言。 Flutter和Dart有什么关系呢？早期的Flutter团队在评估了十多种语言之后才选择了Dart，因为它符合构建用户界面的方式。 Flutter团队看重的Dart语言部分特性（1）Dart是AOT（Ahead Of Time）编译的，编译成快速、可预测的本地代码，使得Flutter几乎都可以使用Dart编写。这不仅使得Flutter变得更快，而且几乎所有的组件（包括所有的小组件）都可以定制。（2）Dart也可以JIT（Just In Time）编译，开发周期非常短，工作流颠覆常规（包括Flutter流行的亚秒级有状态热重载）。（3）Dart可以更轻松的创建以60fps运行的流畅动画和转场。Dart可以在没有锁的情况下进行对象分配和垃圾回收。就像JavaScrip ...

写在前面我们知道分布式系统由多个不同的子系统组成，但是我们希望在使用系统的时只需登录一次就能访问该系统，而不用多次登录，因此单点登录是一个很常见的需求。 在《OAuth2.0+JWT实现单点登录》一文中，我们使用OAuth2+JWT这一技术实现了单点登录，其实正确来说我们实现的是无状态登录，只是这种无状态登录满足单点登录的要求。 前面也说了无状态存在一些缺点，因此接下来我们尝试使用另一种技术，使用SpringBoot+OAuth2.0并结合@EnableOAuth2Sso注解这一方式来实现单点登录。 请注意上述两种实现方案都有其比较适合的场景，因此具体选择哪种需要结合实际情况来进行选择。 初始化项目前面我们都是将授权服务器和资源服务器分开搭建，本篇出于简单考虑，就直接将两者放在一个服务器上，名称统一为“统一认证中心”。此案例除了授权服务器外，还需要多个客户端应用，这里就提供两个。各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器+资源服务器 2019 client-app1 客户端1 2020 client-ap ...

写在前面通过前面几篇的学习，我们对OAuth2.0中的四种授权模式有了较为清晰的认识，同时可以发现这些文章都是侧重于OAuth2.0的登录流程，而对于登录的一些细节并没有过多的深究，其实这些细节在实际开发过程中也非常重要，因此接下来开始对登录中的一些细节进行深度分析。 我们知道传统的Web应用都是采用Session来记录用户认证信息，这一方式可以理解为是一种有状态的登录，实际上还可以采用无状态这种方式来实现这一目的，最为代表的就是JWT。无状态登录很容易实现单点登录这一功能，因此对于无状态登录的研究对于提升自身技术水平有非常大的帮助。 状态有状态所谓的有状态服务是指服务端需要记录每次会话的客户信息，并据此识别客户端身份，验证通过后根据客户端身份进行请求处理，如Tomcat中的session就是此类的具体实现。当用户登录成功后，会将用户的信息保存在服务端的Session中，并将sessionId放在Cookie中用于返回给用户。等到用户下次访问的时候，用户会携带含有Cookie信息的请求到服务器，服务器会验证sessionId是否合法，当验证无误通过后会据此找到用户信息。 但是这种方式存 ...

写在前面一般来说，access_token令牌肯定不会像之前那样存在内存中，通常我们都会将其存入Redis数据库中。在实际开发过程中，不仅仅是令牌，对于客户端信息，我们同样需要将其存入数据库中，还有对于第三方应用而言，前面的配置都显得过于臃肿，因此接下来就尝试对上述一些问题进行细致分析。 项目初始化同样由于授权码模式的完整性，这里依旧选择使用授权码模式进行分析。授权码模式中各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器 8080 user-server 资源服务器 8081 client-app 客户端（第三方应用） 8082 空Maven父工程搭建使用Maven新建一个空白的父工程，名称为authorization-code-redis，之后我们将在这个父工程中搭建子项目。 授权服务器搭建在authorization-code-redis父工程中新建一个子模块，名称为auth-server，在选择依赖的时候选择如下五个依赖：Web、Spring Cloud Security、Spring Cloud O ...

写在前面前面我们对OAuth2.0中四种授权模式进行了学习，接下来将通过一个完整的实例来研究客户端模式，深入理解其中的各个流程。 实例架构客户端模式又称为凭证式模式，当某些应用是纯后端应用没有前端时，就可以使用客户端模式，即在命令行下请求令牌。客户端模式是指客户端使用自己的名义而不是用户的名义向服务器提供者申请授权。严格来说，客户端模式并不能算作OAuth协议要解决的问题的一种解决方案，但是对于开发者而言，在一些前后端分离应用或者为移动端提供的认证授权服务器上使用这种模式还是较为方便的。它涉及到资源所有者、客户端（第三方应用）、授权服务器和资源服务器这三个角色。客户端模式涉及到的各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器 8080 user-server 资源服务器 8081 client-app 客户端（第三方应用） 8082 空Maven父工程搭建使用Maven新建一个空白的父工程，名称为client，之后我们将在这个父工程中搭建子项目。 授权服务器搭建在client父工程中新建一个子模块，名称为 ...

写在前面前面我们对OAuth2.0中四种授权模式进行了学习，接下来将通过一个完整的实例来研究密码模式，深入理解其中的各个流程。 实例架构密码模式是用户把用户密码直接告诉客户端（第三方应用），客户端使用这些信息向授权服务器申请令牌。这就需要用户对客户端高度信任，如客户端和服务提供商是同一家公司。它涉及到资源所有者、客户端（第三方应用）、授权服务器和资源服务器这四个角色。由于用户就是笔者，因此无需提供项目实例，而其他三者这里就提供各自的项目实例，各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器 8080 user-server 资源服务器 8081 client-app 客户端（第三方应用） 8082 空Maven父工程搭建使用Maven新建一个空白的父工程，名称为password，之后我们将在这个父工程中搭建子项目。 授权服务器搭建在password父工程中新建一个子模块，名称为auth-server，在选择依赖的时候选择如下三个依赖：Web、Spring Cloud Security和Spring Clou ...

写在前面前面我们搭建了一个完整的授权码模式实例，接下来就尝试搭建另一个完整的模式实例—简化模式。考虑到后续学习的方便性，这里选择从零开始搭建，而非在此前授权码模式的基础上进行修改，这样能更加直观感受到简化模式和授权码模式的区别。注意所有加粗的地方均表示简化模式与授权码模式的区别，也就是不同之处。 实例架构简化模式又称为隐藏式模式，当某些Web应用是纯前端应用没有后端时，就可以使用简化模式。简化模式允许授权服务器直接向前端颁发令牌，这种方式没有授权码这个中间步骤，所以称为（授权码）”隐藏式”（implicit）。它的特点就是通过客户端的服务器与授权服务器进行交互，涉及到资源所有者（用户）、客户端（第三方应用）、授权服务器和资源服务器这四个角色。由于用户就是笔者，因此无需提供项目实例，而其他三者这里就提供各自的项目实例，各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器 8080 user-server 资源服务器 8081 client-app 客户端（第三方应用） 8082 空Maven父工程搭建使用Mave ...

写在前面前面我们对OAuth2.0中四种授权模式进行了学习，接下来将通过一个完整的实例来研究授权码模式，深入理解其中的各个流程。 实例架构授权码模式是功能最完整、流程最严谨的授权模式。它的特点就是通过客户端的服务器与授权服务器进行交互，涉及到资源所有者（用户）、客户端（第三方应用）、授权服务器和资源服务器这四个角色。由于用户就是笔者，因此无需提供项目实例，而其他三者这里就提供各自的项目实例，各实例项目名称、角色名称和端口如下表所示： 项目名称 角色名称 端口 auth-server 授权服务器 8080 user-server 资源服务器 8081 client-app 客户端（第三方应用） 8082 空Maven父工程搭建使用Maven新建一个空白的父工程，名称为authorization-code，之后我们将在这个父工程中搭建子项目。 授权服务器搭建在authorization-code父工程中新建一个子模块，名称为auth-server，在选择依赖的时候选择如下三个依赖：Web、Spring Cloud Security和Spring Cloud OAut ...

写在前面在《OAuth2.0的一个简单解释》一文中，我们对OAuth2.0的含义和设计思想有了一个较为清晰的认识，那么接下来就学习OAuth2.0中的四种授权模式。 OAuth2角色在学习授权模式之前，了解OAuth2中的4种基本角色对于学习和理解OAuth的工作原理有重要意义。（1）资源所有者：资源所有者即用户，具有头像、照片、视频等资源；（2）客户端：客户端即第三方应用，如前一篇中提到的知乎；（3）授权服务器：授权服务器用来验证用户提供的信息是否正确，并返回一个令牌给第三方应用；（4）资源服务器：资源服务器是提供给用户资源的服务器，如头像、照片、视频等资源。 通常来说，授权服务器和资源服务器可以是同一台服务器。 OAuth2授权流程在熟悉了OAuth2中的4个基本角色以后，接下来开始学习OAuth2的授权流程，具体的流程如下：（1）客户端（第三方应用）向用户请求授权；（2）用户单击客户端所呈现的服务授权页面上的同意授权按钮后，服务端返回一个授权许可凭证给客户端；（3）客户端拿着授权许可凭证去授权服务器申请令牌；（4）授权服务器验证信息无误后，发放令牌给客户端；（5）客户端拿着令牌去 ...

写在前面乘着年尾还有点时间，打算将今年学到的OAth2相关知识进行总结，一来是便于自己对知识点的汇总，二来是怕自己遗忘，写几篇笔记来进行记录。 OAth2快递员问题一开始我也不太明白OAth2这个概念，直到某一天看到阮一峰写的OAth2博客，才对OAth2有了一个更为清晰的理解和认识。他通过一个快递员问题，从身边的事物入手，来理解OAth2的概念。 假设笔者住在一个大型的居民小区，小区有门禁系统，任何人进入的时候需要输入密码。笔者非常喜欢淘货，每天都有快递员来送货，因此笔者必须找到一个办法，让快递员通过门禁系统，进入小区进而给我派件。现在问题来了，如果我把我的密码告诉快递员，那么快递员就拥有了和我一样的权限，这似乎不太合适。还有万一我修改了密码，那我必须告诉所有的快递员，这样它们才能继续进入小区。 那么问题来了，有没有一种办法可以让快递员既可以自由的进出小区，又无需知道小区居民的用户密码，而且他唯一的权限就是派件，其他需要密码的场合，他都不能进，没有对应的权限。 授权机制的设计针对上述问题，笔者设计了一套授权机制。 第一步，在门禁系统的密码输入器下面增加一个按钮，叫做”获取授权”。快递 ...