文章更新

docs/.vuepress/config.ts

@@ -5,7 +5,7 @@ import { backToTopPlugin } from '@vuepress/plugin-back-to-top'
 export default {
   lang: 'zh-CN',
   title: '拔土豆的程序员',
-  description: '不知道咋说，随便写写吧。',
+  description: '没进过大厂|技术一般|创业被坑|普普通通程序员',
   // markdown设置
   markdown:{
     lineNumbers: true, // 代码块行号

docs/design/OAuth/OAuth2和单点登录.md

@@ -0,0 +1,5 @@
+# OAuth2和单点登录
+
+OAuth2.0的应用场景可以理解为单点登录的升级版，单点登录解决了多个系统间会话的共享，OAuth2.0在此基础上增加了应用之间的权限控制 。
+
+有些系统采用OAuth2.0模式实现了单点登录，但这总给人一种“杀鸡焉用宰牛刀”的感觉。

docs/design/OAuth/OAuth基本概念.md

@@ -0,0 +1,23 @@
+# OAuth 2.0 基本概念
+
+OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方。
+
+##  OAuth2 授权流程中的角色
+
+- 资源拥有者（`resource owner`）
+  - 最终用户：能授权访问受保护资源的一个实体，可以是一个人。
+- 资源服务器（`resource server`）
+  - 存储受保护资源，客户端通过`access token`请求资源，资源服务器响应受保护资源给客户端；
+- 授权服务器（`authorization server`）
+  - 成功验证资源拥有者并获取授权之后，授权服务器颁发授权令牌（`Access Token`）给客户端。
+- 客户端（`client`）
+  - 第三方应用，也可以是它自己的官方应用；其本身不存储资源，而是资源拥有者授权通过后，使用它的授权（授权令牌）访问受保护资源，然后客户端把相应的数据展示出来/提交到服务器。
+
+## 四种模式
+
+1. 授权码（Authorization Code）：OAuth2.0标准授权步骤，Server端向Client端下放Code码，Client端再用Code码换取授权Token
+2. 隐藏式（Implicit）：无法使用授权码模式时的备用选择，Server端使用URL重定向方式直接将Token下放到Client端页面
+3. 密码式（Password）：Client直接拿着用户的账号密码换取授权Token
+4. 客户端凭证（Client Credentials）：Server端针对Client级别的Token，代表应用自身的资源授权
+
+![https://oss.dev33.cn/sa-token/doc/oauth2/sa-oauth2-setup.png](image/sa-oauth2-setup.png)

docs/design/OAuth/OAuth常见问题.md

@@ -0,0 +1,67 @@
+# OAuth常见问题
+
+## 前后端分离：登录页面和授权确认页面
+
+问题：
+
+1. OAuth 2 授权的时候会302重定向到授权服务器提供的登录页面和授权确认页面。
+
+原因：
+
+1. OAuth2客户端和授权服务器之间并不是一个完全信任的关系。
+
+例如现在智能门锁已经很普及了，一般都会有临时密码，而不是告诉访客实际密码。
+
+ajax无法安全地处理OAuth2授权流程中的302重定向问题，这也是一个技术问题。
+
+## 常用场景
+
+OAuth2主要用于API授权，是跨API服务之间授权的解决方案。
+
+1. 单点登录（SSO）
+2. 微服务之间的授权鉴权
+3. API开放平台等场景。
+
+## 密码模式为什么被废除
+
+OAuth2.1中密码模式被移除，包括OAuth0、okta等知名三方授权服务机构都对密码模式进行了移除处理。
+
+密码模式诞生的时候，像React、Vue这种单页应用还没有兴起，甚至连框架都还没有呢。它更像一种为了解决遗留问题而采用的过渡方案。在传统应用中，用户习惯了把密码直接交给客户端换取资源访问权限，而不是跳来跳去去拉授权、确认授权。OAuth2诞生之初为了让用户从传统思维中慢慢转变过来就设计了这种模式。 它打破了委托授权的模式，降低了OAuth2的安全性。
+
+## 微服务是否可以不使用OAuth2
+
+可以，OAuth2只不过是目前微服务访问控制的解决方案之一，并不是唯一选项。
+
+## 资源服务器
+
+只要包含了需要OAuth2客户端携带access_token访问的资源接口的服务器都可以认为是资源服务器，包括OAuth2客户端、OAuth2授权服务器都可以根据业务和架构承担资源服务器的功能。从用户（资源所有者）角度来说，存放用户可以授权的资源接口的服务器都可以是资源服务器。资源服务器可以对访问令牌access_token进行解码、校验，并确定本次请求是否合规。
+
+## 客户端认证是什么
+
+confidential类型的OAuth2客户端虽然在OAuth2授权服务器注册，它们要根据一些策略（Client Authentication Method）来向授权服务器证明自己是合法的客户端。这样它们才能调用一些OAuth2规定的端点，比如/oauth2/token令牌端点、/oauth2/revoke令牌撤销端点等等。关于OAuth2客户端认证的细节可以参考OAuth2客户端认证过滤器详解。
+
+## 客户端能否做用户认证
+
+OAuth2本身并没有定义用户如何向OAuth2客户端认证身份，这里要和授权服务器上的用户认证区别开来。OAuth2客户端在完成授权时可以拿到授权凭据，但是并不能直接拿到用户信息，如果授权服务器提供了获取用户信息的资源接口，OAuth2客户端可以通过该接口尝试获取用户信息用来表明用户的身份，这取决于用户是否授权了OAuth2客户端这样做。OIDC 1.0补充定义了OAuth2客户端对用户进行认证的细节流程。
+
+## scope是什么
+
+OAuth2是一个授权框架，授权自然要划定一个范围（scope），以保证OAuth2客户端在既定的范围内行事而不越界。它起到的作用和RBAC中的role其实类似，都是用来限制资源的访问权限的。role针对的是资源拥有者（Resource Owner），而scope针对的是OAuth2客户端。当然有一个例外openid，这个是OIDC 1.0的标识，算一个关键字。
+
+## access_token和refresh_token应该直接返回给前端吗
+
+能不能返回给前端取决于这个前端是不是直接在授权服务器的OAuth2客户端，如果不是，就不能持有access_token和refresh_token，access_token和refresh_token的签发目标只能是OAuth2客户端。如果暴露面放开，则很容易被盗用。
+
+## 非OAuth2客户端的客户端应用既然不能直接持有access_token和refresh_token的话，应该如何获取授权状态
+
+当授权成功后，令牌和用户客户端侧可以借助于session或者cookie进行一个映射，当然也可以考虑计算出一个不透明令牌（ Opaque Token ）映射，具体根据业务考量。
+
+## 客户端为什么分为public和confidential两种类型，分别是什么场景
+
+相关定义参见rfc6749#section-2.1， 根据OAuth2客户端自身是否有能力维护客户端凭据（client credentials）的私密性，是否能安全地通过授权服务器对客户端的资质进行认证将OAuth2客户端分为机密客户端和公共客户端。大部分的后端数据服务都应该被注册为机密客户端；无法保障自身凭据安全的都应该被注册为公共客户端，公共客户端是没有client_sercet的，直接注册到OAuth2授权服务器的执行客户端，不通过后端应用进行访问令牌中继的都是公共客户端，特定场景需要直连授权服务器的Web应用、移动应用都属于这一类。
+
+## 什么是OAuth2客户端
+
+在OAuth2授权服务器上注册为客户端，并获得专属client_id标识的才是OAuth2客户端。
+
+安卓应用、IOS应用、Web前端等客户端应用也要遵循这个原则，它们本身注册到OAuth2授权服务器才能成为OAuth2客户端，否则就不是OAuth2客户端，必须是它们本身，而不是支撑它们的后端服务。

docs/design/OAuth/README.md

@@ -1,2 +1,7 @@
 # OAuth
 
+[OAuth基本概念](./OAuth基本概念.md)
+
+[OAuth2和单点登录](./OAuth2和单点登录.md)
+
+[OAuth常见问题](./OAuth常见问题.md)

docs/design/distributed/README.md

@@ -4,6 +4,8 @@
 
 [高并发性能指标](./高并发性能指标.md)
 
+[微服务中台等等设计](./微服务中台等等设计.md)
+
 ## 分库分表
 
 [分库分表策略以及平滑扩容](./分库分表策略以及平滑扩容.md)

docs/design/distributed/微服务中台等等设计.md

@@ -0,0 +1,21 @@
+# 微服务和中台
+
+- 微服务架构的核心理念是将一个应用拆分成小而自治的服务。
+
+- 中台则在企业内部构建共享的技术平台，以提高效率和协同。
+
+虽然微服务具有灵活性和独立性的优点，但同时也增加了系统复杂性、调试、管理、交付成本。这些挑战需要通过引入微服务治理来解决，治理本身带来一定的成本。
+
+中台的构建需要企业进行组织和文化上的变革，这不是一蹴而就的过程。
+
+
+
+新的理念虽然能够解决当前问题，但并非银弹，根据历史经验，新的理念和技术总会带来新的挑战，比如微服务治理。微服务治理不仅仅包括服务注册、发现、配置中心，还包括DevOps、CI、CD等方面。
+
+在面对一些新的理念货概念（包括微服务、中台），研发人员往往会陷入0/1游戏，对、错的思考模式。然而，更合理的方式是首先了解当前项目或产品所面临的困境和场景，考虑技术引入可能带来的成本和价值，而不是盲目跟从他人观点。
+
+成功的商业公司如Netflix、亚马逊等证明了微服务的有效性，但商业战略上的失败通常涉及多个因素。将责任归咎于微服务或中台显然是一种失偏颇的观点。
+
+这就像产品不成功，把失败的原因归咎于研发人员不给力一样滑稽。
+
+> 摘自：Ahoo-Wang

docs/spring/spring/README.md

@@ -16,3 +16,6 @@
 
 [Spring中事务以及事务的传播机制](./Spring中事务以及事务的传播机制.md)
 
+1、nginx 摘流
+2、等 http、rpc、mq、job 执行完，或者搓一点 sleep 60-120 秒
+3、shutdown

docs/spring/springBoot/OAuth2Client对接认证服务.md

@@ -0,0 +1,30 @@
+# OAuth2 Client对接认证服务
+
+项目在初始化时会根据配置的issuer-uri拼接url，即签发地址根目录/.well-known/openid-configuration，像项目中配置的就是该接口会返回认证服务器的元信息。
+
+```web-idl
+http://127.0.0.1:9000/.well-known/openid-configuration
+```
+
+![image-20231220150034474](image/image-20231220150034474.png)
+
+## cookie 问题
+
+认证服务器和客户端在同一个机器上时不能使用同一个ip。[Not able to connect Spring OAuth2 Authorization Server with Client · Issue #5946 · spring-projects/spring-security (github.com)](https://github.com/spring-projects/spring-security/issues/5946)
+
+可以一个使用 192.168.18.14:9001（内网）一个使用 127.0.0.1
+
+## 客户端
+
+客户端在oauth2角色解释中是第三方的一个应用，一般会配合资源服务一起使用。
+
+单体项目
+
+- 会同时添加资源服务依赖，客户端负责调用认证服务登录，资源服务器负责解析获取到的token，然后获取token中的权限，目前token中的权限只有scope的权限，并且不太好自定义，所以就需要通过资源服务器配置去更好的解析token。
+
+
+
+分布式项目：
+
+- 在网关中添加客户端依赖，检查用户认证信息，由网关代理的微服务添加资源服务依赖，解析网关通过令牌中继的方式携带的access_token；各个微服务添加自己的授权校验。
+- 在网关中集成客户端依赖，同时集成资源服务依赖，由网关检查用户的认证和授权信息；各个微服务不用添加任何的认证与授权相关的处理，可以直接访问；这种方式需要屏蔽各微服务其它ip的访问，只能由网关代理访问。

docs/spring/springBoot/README.md

@@ -2,6 +2,32 @@
 
 梳理 Spring Boot 相关内容。
 
+## spring-authorization-server
+
+示例项目：[lizhifuabc/spring-authorization-server-example: Spring OAuth2 Authorization Server 集成，认证服务、第三方登录、自定义grant_type等等 (github.com)](https://github.com/lizhifuabc/spring-authorization-server-example)
+
+
+
+[01基本概念](./基本概念.md)
+
+[SpringAuthorizationServer-02](./SpringAuthorizationServer-02.md)
+
+[03自定义异常响应配置](./SpringAuthorizationServer-03.md)
+
+[04常用端点](./常用端点.md)
+
+[客户端认证授权.md](./客户端认证授权.md)
+
+[资源服务器](./资源服务器.md)
+
+[SpringAuthorizationServer-07](./SpringAuthorizationServer-07.md)
+
+[SpringAuthorizationServer-08](./SpringAuthorizationServer-08.md)
+
+[SpringAuthorizationServer-09](./SpringAuthorizationServer-09.md)
+
+[SpringAuthorizationServer-10](./SpringAuthorizationServer-10.md)
+
 ## 项目地址
 
 [lizhifuabc/spring-learn: springboot3、springcloud、java基础 (github.com)](https://github.com/lizhifuabc/spring-learn)

docs/spring/springBoot/SpringAuthorizationServer-02.md

@@ -0,0 +1,9 @@
+# SpringAuthorizationServer-02
+
+
+
+## 自定义用户登录页
+
+## 自定义用户确认授权页
+
+## 自定义RegisteredClientRepository

docs/spring/springBoot/SpringAuthorizationServer-03.md

@@ -0,0 +1,11 @@
+# 自定义异常响应配置
+
+Spring Security中的异常主要分为两大类
+
+- 认证异常（`AuthenticationException`），这个是所有认证异常的父类
+- 权限异常（`AccessDeniedException`），这个是所有权限异常的父类
+
+
+
+按照oauth协议，异常信息放在响应头中，响应头的key是**WWW-Authenticate**。
+