最近接触到一个比较常见的需求，用户在获取线上资源时，需要先对用户的身份进行认证，认证通过之后用户可以正常的下载相关的资源。这个过程中，其实主要是以下功能点
- 验证用户的身份
- 将用户请求的url转换到实际的资源上
其中，验证身份的功能与具体业务有关，所以在这里主要是介绍一下如何将url转换到实际的资源上。对于这个做法，最直接的想法就是服务端在验证用户身份之后，直接读取资源然后写入输出流，用户即可获取对应的资源。这种方案的问题是，资源在业务服务上面做转了一手。如果你的业务系统中有采用nginx进行分发，也可以试试本文这边比较有意思的方案，借助nginx的error_page功能进行内部跳转，从而达到url隐藏的功能。
首先，使用nginx-url-hide用来模拟url到资源的映射，该项目使用的spring boot 2.4.2构建的项目。具体的controller如下。最关键的代码是将具体的资源地址放到了response的header中，并且返回了一个自定义的http status code （599）。这个状态码将在抛出之后，被nginx所捕获，并根据header中的target字段下载指定的资源。
package cn.yxsk.application;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Controller;
import org.springframework.util.ObjectUtils;
import org.springframework.util.StringUtils;
import org.springframework.web.bind.annotation.RequestMapping;
@Controller
public class CheckUrlController {
private static final Logger LOGGER = LoggerFactory.getLogger(CheckUrlController.class);
private static final int REDIRECT_CODE = 599;
private final Map<String, String> targetUri;
public CheckUrlController() {
Map<String, String> targetUri = new HashMap<>();
targetUri.put("/res1", "/hello.jpg");
this.targetUri = Collections.unmodifiableMap(targetUri);
}
@RequestMapping("**")
public void check(HttpServletRequest request, HttpServletResponse response) {
String query = request.getQueryString();
LOGGER.debug("请求的url地址为{}", request.getRequestURL().append("?").append(query));
String uri = request.getRequestURI();
String target = this.targetUri.get(uri);
if (ObjectUtils.isEmpty(target)) {
response.setStatus(HttpStatus.NOT_FOUND.value());
} else {
StringBuilder targetUri = new StringBuilder(32).append(target);
if (StringUtils.hasText(query)) {
targetUri.append("?").append(request.getQueryString());
}
response.setHeader("target", targetUri.toString());
response.setStatus(REDIRECT_CODE);
}
}
}
其中nginx的配置如下。nginx在捕获到自定义的状态码之后，进行了一个内部重定向，因此这个资源是无法在客户端直接被访问到的，只有通过业务服务器隐藏的地址才能够进行访问。通过对请求的预处理，可以对用户的请求进行限制。
server {
listen 80;
server_name redirect.yxsk.cn;
fastcgi_intercept_errors on;
proxy_intercept_errors on;
location / {
proxy_http_version 1.1;
proxy_redirect off;
proxy_set_header Connection "";
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Cookie $http_cookie;
proxy_pass http://127.0.0.1:7070;
error_page 599 = @inner_redirect;
}
location @inner_redirect {
set $target $upstream_http_target;
root /data/wwwroot/res-static;
try_files $target $document_root;
}
}
在整个nginx配置中，最关键的是如下的几个配置，其中
- error_page ：用于捕获错误码信息，然后进行一次nginx的内部跳转。配置说明
- proxy_intercept_errors：该配置用于确定大于300的状态码，是否直接返回给客户端还是允许nginx进行一次内部处理，此配置主要是用于proxy_pass 的配置。配置说明
- fastcgi_intercept_errors：与proxy_intercept_errors的作用类似，只是用于FastCGI 服务返回的状态码。配置说明
采用proxy_intercept_errors还是fastcgi_intercept_errors取决于请求转发给后端业务服务器的方式。对于业务服务器写入的header字段target，在nginx的配置文件获取时为$upstream_http_target
当然，该方法目前目前一定的限制，这个限制主要是error_page 的限制。无论客户端采用的是post还是get，经过error_page的内部跳转之后，都会被转为get
有没有什么有意思的小需求，可以提供一下一起探讨的
