请教一个问题，为什么使用中间件而不是守卫来实现身份验证？

[zuozuomuxi]

• Node Version:
• Midway Version(Decorator/Core):
• Component Name/Version:
• Platform:
• Mini Showcase Repository:

在文档的身份验证部分，示例代码是使用中间件来实现的，@midwayjs/passport 这个包也只提供了 PassportMiddleware，但这应该是典型的 守卫guard 的使用场景吧，为什么要用中间件而不是守卫来做呢？如果要改成使用守卫的模式应该怎么做？

[czy88840616]

身份验证和鉴权是两个事情，身份验证是根据提供的用户名密码或者token拿到一个合法的用户信息，用户角色，这样鉴权组件才能根据这些去查询角色权限，这个时候才要去关心是否能访问路由，才是守卫的范畴。身份验证在先，鉴权在后，所以身份获取用的中间件，而鉴权用的守卫。

[zuozuomuxi]

身份验证和鉴权是两个事情，身份验证是根据提供的用户名密码或者token拿到一个合法的用户信息，用户角色，这样鉴权组件才能根据这些去查询角色权限，这个时候才要去关心是否能访问路由，才是守卫的范畴。身份验证在先，鉴权在后，所以身份获取用的中间件，而鉴权用的守卫。

你的解释有道理，但我看了下 nestjs 是使用守卫来实现的，我觉得用守卫也能说得通，并且写法稍微优雅一点，你们可以酌情考虑下在 @midwayjs/passport 中提供一个守卫的实现

[zuozuomuxi]

再打扰一下，说个题外话，我因为这个问题看了下 @midwayjs/passport 的源码，我发现组件的实现代码还需要考虑底层使用的框架是 express 还是 koa/egg，并做不同的处理，我觉得应该在核心层就抹平这个差异，例如提供getRequest 和 getResponse 方法，返回一样的实现，组件的实现就不需要考虑底层框架了，以后添加其他框架也不需要改组件代码。 我只是非常浅地看了下代码，说得不对的话请指教。

[czy88840616]

nestjs 和 midway 本质上都是基于不同的 web framework去包裹出不同的行为，但是即使是相同的名字，其实现逻辑可能还是不同的。

由于路由模块本身的原因，我们定义路由之前都是中间件，而进入了具体的路由方法，到执行之前，则是守卫的范畴，中间件和守卫的最大区别是是否能拿到路由的元信息去处理事务，中间件不行，而守卫可以。

至于 passport 使用的是中间件，是因为其必须在鉴权之前，拿到用户信息，如果是守卫，这个顺序会交给用户在每个方法和装饰器层面去保证，几乎不可能（但是在逻辑上提供守卫的方法是可能的，只是这样做不是很好，用户会选择障碍）。

[czy88840616]

再打扰一下，说个题外话，我因为这个问题看了下 @midwayjs/passport 的源码，我发现组件的实现代码还需要考虑底层使用的框架是 express 还是 koa/egg，并做不同的处理，我觉得应该在核心层就抹平这个差异，例如提供getRequest 和 getResponse 方法，返回一样的实现，组件的实现就不需要考虑底层框架了，以后添加其他框架也不需要改组件代码。 我只是非常浅地看了下代码，说得不对的话请指教。

我们简单的把 Web 框架分为类 express 和 类 koa 两种，所以官方提供的功能会把两种都兼容一下，如果自己业务写就没这个必要，只适配自己的业务就好。

另外由于 midway 还会把 grpc 等其他 framework 考虑进来，所以不能单纯的提供 getRequest/response 这种抽象方法。

[waitingsong]

身份认证： authentication 你是谁 身份鉴（授）权：authorization 你可以做什么

中间件判断你是谁，具体的守卫判断你能做什么，这样就能想通了。

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.