设计模式实战-设计模式01-优快云博客

本文链接：https://blog.youkuaiyun.com/wjl31802/article/details/141092371

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

文章目录

第三方账号登录

第三方账号登录

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

啥意思？

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

优点：

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

缺点：

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

实现步骤：

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

2. 仅进行登录

优点：

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

缺点：

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

实现步骤：

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

综合考虑

自动注册的，只不过这部分功能对用户来说是无感知的。如果仅仅提供登录，不自动注册的话，咱们的项目无法留存用户信息，也没办法进行准确的用户群体数据分析（如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.youkuaiyun.com/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过期逻辑需要根据项目的真实访问情况而定，因此仅仅提供了核心的交互过程。