四十、登陆-sessionid鉴权

目录

一、将sessionID持久化

1、这里的GetAuthKey函数创建sessionID保存的key

二、完成鉴权方法Auth

三、在路由方法中增加需要鉴权的路由

四、自行测试


一、将sessionID持久化

//sessionid持久化
	authKey := utils.GetAuthKey(sessionID)
	err = c.rdb.Set(ctx, authKey, time.Now().Unix(), time.Hour*8).Err()
	if err != nil {
		fmt.Printf("rdb.Set err: %+v\n", err)
		return "", err
	}
1、这里的GetAuthKey函数创建sessionID保存的key
func GetAuthKey(sessionID string) string {
	authkey := fmt.Sprintf("session_auth:%s", sessionID)
	return authkey
}

二、完成鉴权方法Auth

func (s *SessionAuth) Auth(ctx *gin.Context) {
	sessionID := ctx.GetHeader(SessionKey)
	if sessionID == "" {
		//如果没有获取到sessionID则执行终端,并返回403错误码
		ctx.AbortWithStatusJSON(http.StatusForbidden, "session_id is empty")
	}
	authKey := utils.GetAuthKey(sessionID)
	loginTime, err := s.rdb.Get(ctx, authKey).Result()
	if err != nil && err != redis.Nil {
		//获取错误情况下中断
		ctx.AbortWithStatusJSON(http.StatusInternalServerError, "session auth error")
	}
	if loginTime == "" {
		//获取为空情况下中断
		ctx.AbortWithStatusJSON(http.StatusUnauthorized, "session auth failed")
	}
	//能够正常获取sessionid的情况下继续执行
	ctx.Next()
}

三、在路由方法中增加需要鉴权的路由

session := newSessionAuth()

//需要鉴权
root := r.Group(rootPath).Use(session.Auth)

四、自行测试

<think>好的,我现在需要帮助用户了解认证、登录和的架构设计,并且根据提供的引用内容来整理回答。首先,我得理清认证、登录和这三个概念的区别和联系。认证是验证用户身份,登录是用户进入系统的过程,而则是确定用户是否有限访问资源。接下来,我需要结合用户提供的引用内容来构建一个清晰的架构设计方案。 引用[1]提到登录验证是系统的第一步,也是最简单的一步。这说明在设计系统时,登录验证是基础,需要先处理用户身份的确认。引用[2]和[3]则讨论了单点登录(SSO)和微服务中的Token,尤其是使用网关统一处理,这可以作为架构设计的重要部分。引用[4]和[5]提到了Token注销的问题以及网关在中的作用,需要考虑到令牌管理的有效性和网关层的统一处理。 首先,我需要明确整个流程:用户登录时如何认证,认证成功后如何生成令牌,令牌如何在各个子系统或服务之间传递和验证。然后,的部分需要设计限模型,比如RBAC(基于角色的访问控制)或ABAC(基于属性的访问控制),并结合网关统一来减少各服务的负担。 接下来要考虑的是架构的分层设计,可能包括认证中心、网关层、业务服务层。认证中心处理用户认证并颁发Token,网关负责统一,验证Token的有效性并转发请求到对应的服务。业务服务则无需处理逻辑,只需信任网关传递的信息。 还需要考虑安全性,比如Token的存储、传输加密、刷新机制以及注销问题。引用[4]提到Token注销的困难,可能需要引入令牌黑名单或者短时效的Token结合刷新令牌来解决。同时,引用[5]强调网关层处理,使得业务服务透明,这样的设计可以减少重复工作,提高系统的可维护性。 此外,单点登录(SSO)的实现需要独立的认证中心,各子系统通过该中心进行登录,引用[2]详细描述了这一过程,包括全局会话和局部会话的创建,以及Token的分发。这部分需要整合到架构设计中,确保多个系统间的无缝认证。 最后,需要总结常见的实现方案,比如JWT、OAuth2、OpenID Connect等技术,并结合引用中的例子,如Spring Cloud Gateway和Feign的内部调用,说明如何在微服务架构中应用这些技术。同时,要提到未来的扩展方向,如高可用性、分布式会话管理、多因素认证等,以展示系统的可扩展性和安全性。 在回答过程中,要确保使用正确的中文术语,结构清晰,分点说明,并且自然地引用提供的参考资料。同时,按照用户的要求生成相关问题,这些问题应该覆盖架构设计的各个方面,帮助用户深入理解每个部分。</think>### 认证、登录与架构设计解析 #### 一、核心概念区分 1. **认证(Authentication)** 验证用户身份的过程,例如通过用户名密码、短信验证码、生物识别等方式确认用户身份[^1]。 2. **登录(Login)** 用户发起认证请求并建立会话(Session)或令牌(Token)的交互流程。 3. **(Authorization)** 在认证基础上,判断用户是否有限访问特定资源或操作,例如基于角色或限标签的访问控制。 --- #### 二、典型架构设计方案 ##### 方案1:统一网关(适合微服务架构) - **架构分层** - **认证中心**:负责用户身份核验,生成令牌(如JWT),支持SSO单点登录[^2][^5]。 - **网关层**(如Spring Cloud Gateway):统一拦截请求,验证Token有效性,解析用户身份并转发至下游服务[^3]。 - **业务服务**:仅处理业务逻辑,依赖网关传递的结果(如用户ID、角色)。 ```plaintext 用户 → 网关() → 微服务(业务处理) ``` - **Token管理** - 使用短时效Access Token + 长时效Refresh Token组合,减少令牌泄露风险。 - Token注销依赖网关层维护黑名单或强制Token失效[^4]。 ##### 方案2:独立SSO认证中心(适合多子系统场景) - **流程示例** 1. 用户访问子系统A,跳转至SSO认证中心登录。 2. 认证中心验证身份后颁发全局Token,并重定向回子系统A。 3. 子系统A通过Token向认证中心申请局部会话(如Cookie),完成登录[^2]。 - **特点** - 所有子系统共享认证状态,避免重复登录。 - 依赖Token传递和加密协议(如OAuth2、OpenID Connect)。 --- #### 三、关键实现技术 1. **令牌标准** - **JWT**:自包含Token,包含用户信息与签名,减少服务端状态存储。 - **OAuth2**:适用于第三方授(如微信登录)。 - **Session-Cookie**:传统方案,需配合分布式Session存储(如Redis)。 2. **限模型** - **RBAC**(基于角色):用户-角色-限三级映射。 - **ABAC**(基于属性):动态规则(如时间、IP地址)控制访问。 3. **安全增强** - HTTPS加密传输。 - 多因素认证(MFA)。 - 风险检测(异常登录提醒)。 --- #### 四、挑战与优化方向 1. **Token注销问题** - 网关维护Token黑名单(需考虑性能)[^4]。 - 缩短Token有效期,依赖Refresh Token轮换[^5]。 2. **分布式会话一致性** - 使用Redis集群存储Session或Token状态。 - 无状态JWT方案减少服务端依赖。 3. **高可用性** - 认证中心与网关层需集群部署,避免单点故障。 - 熔断机制(如Hystrix)防止服务雪崩。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值