概述
DailyMart是一个ToC的在线购物商城,目前仅支持通过浏览器访问。在商城中的所有操作都需要用户先登录。为了实现这一需求,我们可以采用以下技术方案:
- 用户通过SpringCloud Gateway访问CustomerService进行登录认证。认证成功后,服务器返回一个JWT(JSON Web Token)。在接下来的操作中,用户需要在请求头中携带此Token。
- 在网关服务中,我们创建了一个名为ApiAuthenticatorFilter的过滤器。该过滤器用于验证请求头中是否包含Token,并检查Token的有效性。如果请求头中没有携带Token,或者Token失效,则不允许访问后端接口。
详细交互流程如下图1所示:
图1:PC认证流程
多端认证需求
这种架构在初期可以满足业务的发展需求。然而,随着业务的扩展,我们需要考虑到现在大部分用户使用手机进行购物的情况。因此,DailyMart也需要支持手机端访问。但与浏览器不同,手机端的认证机制可能会有所不同。
例如,浏览器端的Token有效期通常设定为1小时,而手机端的Token有效期通常设置为7天或更长。此外,浏览器端的Token采用JWT这种去中心化的认证机制,而手机端的Token采用中心化的认证机制,需要调用手机端服务进行登录认证。
同时,为了扩展业务,其他一些第三方应用可能也需要调用DailyMart的后端服务来获取数据,对于第三方的应用一般采用appId + appSecret的方式进行认证,同时需要对接口参数进行签名防止出现篡改和重放。(此方案在前文中有详细说明,可以通过链接跳转访问查看。)
现在的问题是,如何在原有架构的基础上满足这三种不同形式的认证需求呢?
图片
解决方案
要解决这个问题,最关键在于如何判断请求的来源,是来自浏览器端的请求、手机端的请求还是第三方的请求?
我们可以通过请求路径进行区分,对于不同端的请求使用不同的路径进行标识,可以做如下约定:
- 手机端请求,需要在请求路径上带有/ph/
- 浏览器请求,需要在请求路径上带有/pd/
- 第三方请求,需要在路径请求上带有/pt/
- ...
最终规定接口的完整请求路径为:/服务名/api/来源标识/接口路径/,如:http://localhost:9090/customer-service/api/pd/customer/info
这样在SpringCloud Gateway网关先获取请求的路径,再根据请求的路径判断请求来源,最后根据请求来源实现不同的认证方案。
解决这个问题的关键在于如何判断请求的来源,即是来自浏览器端、手机端还是第三方应用?
我们可以通过请求路径进行区分,对于不同端的请求使用不同的路径进行标识。例如:
- 手机端请求,在请求路径上带有 /ph/
- 浏览器端请求,在请求路径上带有 /pd/
- 第三方请求,在请求路径上带有 /pt/
- ...
最终,我们规定接口的完整请求路径为:/服务名/api/来源标识/接口路径/,例如:http://localhost:9090/customer-service/api/pd/customer/info
这样,在SpringCloud Gateway网关中,我们需要创建一个过滤器,首先获取请求的路径,然后根据请求的路径判断请求来源,最后根据请求来源实现不同的认证方案。
代码实现
有了解决方案,我们就很容易完成代码实现了。
为了满足多端认证的需求,在网关服务中我们可以抽取一个公共的认证接口ApiAuthenticator,具体的认证逻辑由具体实现类实现。
图片
在上面的类图中,ProtectedApiAuthenticator用于实现第三方的认证逻辑,DefaultApiAuthenticator用于实现浏览器端的认证逻辑。
在网关过滤器ApiAuthenticatorFilter中,我们首先根据请求路径获取请求来源,然后根据请求来源找到对应的实现类。
@Component
@Slf4j
public class ApiAuthenticatorFilter implements GlobalFilter, Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
URI uri = exchange.getRequest().getURI();
String rawPath = uri.getRawPath();
// 静态接口直接过滤
if (handleExcludeUrl(rawPath)) {
return chain.filter(exchange);
}
// 获取认证逻辑
ApiAuthenticator apiAuthenticator = getApiAuthenticator(rawPath);
AuthenticatorResult authenticatorResult = apiAuthenticator.auth(exchange);
if (!authenticatorResult.isResult()) {
return Mono.error(new HttpServerErrorException(
HttpStatus.METHOD_NOT_ALLOWED, authenticatorResult.getMessage()));
}
return chain.filter(exchange);
}
/**
* 确定认证策略
* @param rawPath 请求路径
*/
private ApiAuthenticator getApiAuthenticator(String rawPath) {
String[] parts = rawPath.split("/");
if (parts.length >= 4) {
String parameter = parts[3];
return switch (parameter) {
case PROTECT_PATH -> new ProtectedApiAuthenticator();
case PRIVATE_PATH -> new PrivateApiAuthenticator();
case PUBLIC_PATH -> new PublicApiAuthenticator();
case DEFAULT_PATH -> new DefaultApiAuthenticator();
default -> throw new IllegalStateException("Unexpected value: " + parameter);
};
}
return new DefaultApiAuthenticator();
}
}
以下是浏览器端的认证逻辑,它会验证JWT token的有效性。如果token失效,则直接返回错误提示给用户,引导其重新登录。
@Component
@Slf4j
public class DefaultApiAuthenticator implements ApiAuthenticator {
@Override
public AuthenticatorResult auth(ServerWebExchange exchange) {
ServerHttpRequest request = exchange.getRequest();
HttpHeaders httpHeaders = request.getHeaders();
// 获取JWT请求头 Authorization
String token = httpHeaders.getFirst(HttpHeaders.AUTHORIZATION);
if (Objects.nonNull(token)) {
try {
String subjectFromJWT = JwtUtil.getSubjectFromJWT(token);
log.info("用户请求token: {} , 身份Subject:{}", token, subjectFromJWT);
//重新设置请求头
mutateNewHeader(exchange, subjectFromJWT);
return new AuthenticatorResult(true, "认证通过");
} catch (ParseException | JOSEException e) {
log.error("token解析失败");
return new AuthenticatorResult(false, "Token错误,请重新登录!");
}
}
return new AuthenticatorResult(false, "Token为空,请重新登录!");
}
}
小结
本文提出了一种灵活、可扩展的方案,以满足 DailyMart 在业务发展过程中的多端认证需求。通过使用请求路径区分不同端的请求来源,并在 SpringCloud Gateway 网关中实现相应的过滤器进行认证,方案具有灵活性、可扩展性和可维护性。