设计模式实战-设计模式01

对应代码见github 参考 《贯穿设计模式》

第三方账号登录

第三方账号授权登录的话，需要自动注册用户第三方账户信息呢？还是说只进行登录

啥意思？

1.自动注册用户第三方账户信息

优点：

• 用户无需手动创建账户，简化了注册流程。
• 可以快速获取用户的第三方账户信息，便于后续的数据分析和个性化服务。

缺点：

• 用户可能不希望应用保存其第三方账户信息。
• 需要处理用户隐私和数据保护的问题，确保符合相关法律法规。

实现步骤：

1. 用户选择使用第三方账号（如微信、QQ、Google 等）进行登录。
2. 应用通过 OAuth 或其他授权协议与第三方平台进行交互，获取用户的授权。
3. 第三方平台返回一个授权码或访问令牌。
4. 应用使用授权码或访问令牌获取用户的第三方账户信息。
5. 应用自动为用户创建一个本地账户，并将第三方账户信息与本地账户关联。

2. 仅进行登录

优点：

• 用户可以选择是否将第三方账户信息与本地账户关联。
• 更加尊重用户的隐私选择。

缺点：

• 用户需要手动创建本地账户，增加了注册流程的复杂性。
• 无法直接获取用户的第三方账户信息，可能需要用户手动输入或通过其他方式获取。

实现步骤：

1. 用户选择使用第三方账号进行登录。
2. 应用通过 OAuth 或其他授权协议与第三方平台进行交互，获取用户的授权。
3. 第三方平台返回一个授权码或访问令牌。
4. 应用使用授权码或访问令登录到本地系统。
5. 如果用户尚未创建本地账户，提示用户创建账户或提供其他登录方式（如邮箱、手机号等）。

综合考虑

自动注册的，只不过这部分功能对用户来说是无感知的。如果仅仅提供登录，不自动注册的话，咱们的项目无法留存用户信息，也没办法进行准确的用户群体数据分析（如QQ用户占30%，微信用户占60%，Gitee账户占5%，传统用户名-密码用户占5%）​。所以必须进行自动注册

项目中用户名的命名规则是什么

暂且使用“第三方平台@用户名”这个格式作为用户名规则

这个需求对实现方式有具体要求吗？使用重构还是扩展？

使用扩展的话，可以使用适配器模式，进行对已有注册和登录功能的适配。不影响已有功能，适配第三方账号的注册和登录功能，增加类的透明度，提高灵活性和复用性。

重构肯定会对原有逻辑进行一定的修改，但是不会修改到主体核心逻辑，不会有太大的影响，重构完成后需要进行测试，问题不大。如果使用重构的话，我建议使用桥接模式，把抽象和实现解耦。而且桥接模式的扩展性很高，您也说了，后续公司还会引入更多的第三方账号，所以从后续扩展性上考虑的话，用桥接模式进行重构也是很不错的方式。

微信、QQ和Gitee的授权申请拿到了吗？一般三方授权申请需要三五天的时间

微信和QQ的授权申请正在进行中，估计还得等几天。Gitee的好办，我申请下Gitee的第三方授权，然后把Client ID和Client Secret发给你们。你们先用Gitee的三方授权开发，等微信和QQ的授权下来，再加到项目里就行

把Callback接口先定一下，申请Gitee授权需要用

先用http://localhost:8081/gitee吧

https://gitee.com/api/v5/oauth_doc#/

适配器的具体适配

![[Pasted image 20240810114413.png]]

适配器(Adapter)角色，既能够支持已有功能（用户名／密码登录）​，也能够适配扩展功能（第三方账号授权登录）​，适配的扩展功能还能够复用已有的方法（register方法和login方法）

gitee的第三方应用，参考 https://blog.csdn.net/weixin_47255175/article/details/122279964

应用名称： book通过gitee登录
clientid:
e006f72878685a5d8bf8ccb195e45cd037600211dcb77939daaef429bfc381c3
client secret
d2d4618c7f39cee2dea244db28999813ed4b562ca8fde537110fe9d95f4a56c6

整个过程
![[Pasted image 20240810120847.png]]

流程

发起第三方登录

https://gitee.com/oauth/authorize?client_id=e006f72878685a5d8bf8ccb195e45cd037600211dcb77939daaef429bfc381c3& redirect_uri=http://localhost:8081/gitee&response_type=code&state=GITEE

返回code
Gitee平台会回调我们刚刚创建的http://localhost:8081/gitee接口，并携带code参数和state参数

请求Token（携带code，POST）
获取到Gitee平台为我们生成的code参数后，继续访问Gitee平台的/oauth/Token接口获取Token

https://gitee.com/oauth/token?grant_type=authorization_code&client_id=e006f72878685a5d8bf8ccb195e45cd037600211dcb77939daaef429bfc381c3&client_secret=d2d4618c7f39cee2dea244db28999813ed4b562ca8fde537110fe9d95f4a56c6&code=xxx&redirect_uri=http://localhost:8081/gitee

获取Token

请求用户信息（携带Token参数，GET）
项目后端继续向Gitee平台的/api/v5/user接口发送请求获取用户信息。此处仅有一个参数，即access_token

https://gitee.com/api/v5/user?access_token=d52bcf7e0a1090a31c6a

获取用户信息
处理第5步请求的返回值，获取的用户信息，并进行“自动注册”和登录

返回登录成功

为什么没有介绍refresh_token流程？也没有介绍Token的过期时间？

未引入refresh_token和Token过期时间的原因是：第三方账号登录几乎为一次性的请求，启用refresh_token逻辑和Token过期逻辑需要根据项目的真实访问情况而定，因此仅仅提供了核心的交互过程。