Spring Cloud combat tips: Zuul handles cookies and redirects

Since we have used a simple interface implementation for HTTP requests in all the previous introductory tutorials. In actual use, our HTTP requests are much more complicated. For example, when we use Spring Cloud Zuul as an API gateway to access website applications, we often encounter the following two very common problems:

Session cannot be maintained
HOST error after redirection

This article will help you analyze the cause of the problem and give solutions to these two common problems.

1. The problem of session retention

By tracking an HTTP request through Zuul to a specific service, and then to the whole process of returning the result. We can easily find that in the process of transmission, the Cookie and Authorization in the HTTP request header information are not correctly passed to the specific service, so the phenomenon that the session state is not maintained eventually.

So where is this information lost? Let's take a look at Zuul's routing and forwarding filters as a starting point. The following is a snippet of the implementation of the RibbonRoutingFilter filter:

public class RibbonRoutingFilter extends ZuulFilter{
...
protected ProxyRequestHelper helper;
@Override
public Object run() {
RequestContext context = RequestContext.getCurrentContext();
this.helper.addIgnoredHeaders ();
try {
RibbonCommandContext commandContext = buildCommandContext(context);
ClientHttpResponse response = forward(commandContext);
setResponse(response);
return response;
}
...
return null;
}
protected RibbonCommandContext buildCommandContext(RequestContext context) {
HttpServletRequest request = context.getRequest();
MultiValueMap<String, String>headers = this.helper
.buildZuulRequestHeaders(request);
MultiValueMap<String, String>params = this.helper
.buildZuulRequestQueryParams(request);
...
}
}

There are three important elements here:

The core logic run function implementation of the filter, which calls the internal function buildCommandContext to build the context content
The buildZuulRequestHeaders method of the helper object is called in the buildCommandContext to process the request header information
The helper object is an instance of the ProxyRequestHelper class

Next, let's look at the implementation of ProxyRequestHelper:

public class ProxyRequestHelper {
public MultiValueMap<String, String> buildZuulRequestHeaders(
HttpServletRequest request) {
RequestContext context = RequestContext.getCurrentContext();
MultiValueMap<String, String>headers = new HttpHeaders();
Enumeration<String>headerNames = request.getHeaderNames();
if (headerNames != null) {
while (headerNames.hasMoreElements()) {
String name = headerNames.nextElement();
if (isIncludedHeader(name)) {
Enumeration<String>values = request.getHeaders(name);
while (values.hasMoreElements()) {
String value = values.nextElement();
headers.add(name, value);
}
}
}
}
Map<String, String>zuulRequestHeaders = context.getZuulRequestHeaders();
for (String header : zuulRequestHeaders.keySet()) {
headers.set(header, zuulRequestHeaders.get(header));
}
headers.set(HttpHeaders.ACCEPT_ENCODING, "gzip");
return headers;
}
public boolean isIncludedHeader(String headerName) {
String name = headerName.toLowerCase();
RequestContext ctx = RequestContext.getCurrentContext();
if (ctx.containsKey(IGNORED_HEADERS)) {
Object object = ctx.get(IGNORED_HEADERS);
if (object instanceof Collection && ((Collection<?>) object).contains(name)) {
return false;
}
}
...
}
}

From the above source code, we can see that buildZuulRequestHeaders, the method of constructing header information, uses the isIncludedHeader function to determine whether each header information of the current request is in the list of ignored header information. If so, it will not be organized into the forwarded request. So where are these ignored headers initialized? In the PreDecorationFilter filter of the PRE stage, we can find the answer:

public class PreDecorationFilter extends ZuulFilter{
...
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
final String requestURI = this.urlPathHelper.getPathWithinApplication(ctx.getRequest());
Route route = this.routeLocator.getMatchingRoute(requestURI);
if (route != null) {
String location = route.getLocation();
if (location != null) {
ctx.put("requestURI", route.getPath());
ctx.put("proxy", route.getId());
// handle the part that ignores the header information
if (!route.isCustomSensitiveHeaders()) {
this.proxyRequestHelper.addIgnoredHeaders (
this.properties.getSensitiveHeaders()
.toArray(new String[0]));
} else {
this.proxyRequestHelper.addIgnoredHeaders (
route.getSensitiveHeaders()
.toArray(new String[0]));
}
...
}

From the above source code, we can see that there is an if/else block that calls the addIgnoredHeaders method of ProxyRequestHelper to add the information that needs to be ignored into the request context for use by the filter in the subsequent ROUTE stage. The if/else blocks here are used to deal with the sensitive header information set globally and the sensitive header information set by the specified route respectively. The global sensitive header information is defined in ZuulProperties:

@Data
@ConfigurationProperties("zuul")
public class ZuulProperties{
private Set<String>sensitiveHeaders = new LinkedHashSet<>(
Arrays.asList("Cookie", "Set-Cookie", "Authorization"));
...
}

So the idea of solving this problem is also very simple, we only need to set sensitiveHeaders, there are two setting methods:

1. Global settings:

zuul.sensitive-headers=

2. Specify the routing settings:

zuul.routes..sensitive-headers=
zuul.routes..custom-sensitive-headers=true

The problem of redirection

When using Spring Cloud Zuul to connect to the Web site, after dealing with the issue of session control. We often encounter the problem shown in the figure below. We initiate a login request through Zuul in the browser, and the request will be routed to a WebSite service. After the service completes the login process, it will be redirected to a certain website. a home page or welcome page. At this point, careful developers will find that after the login is completed, the HOST part of the URL in our browser has changed, and the address has become the address of the specific WebSite service. That's the redirection problem we'll analyze and solve in this section!

The root cause of this problem is that Spring Cloud Zuul does not properly handle the Host in the HTTP request header. In the Brixton version, Spring Cloud Zuul's PreDecorationFilter filter implementation does not consider this issue at all, and it is more positioned as a gateway to the REST API. So it is relatively complicated to add this feature to the Brixton version, but fortunately after the Camden version, the Spring Cloud Netflix 1.2.x version of Zuul has enhanced this feature, we only need to configure the property zuul.add-host-header =true will allow the problematic redirection to be handled correctly. For the processing of more Host header information, readers can refer to the analysis ideas before this article, and you can check the source code of the PreDecorationFilter filter for more implementation details.

Default filtered headers

spring-cloud-netflix-core-1.2.6.RELEASE-sources.jar!/org/springframework/cloud/netflix/zuul/filters/ZuulProperties.java


/**
     * List of sensitive headers that are not passed to downstream requests. Defaults to a
     * "safe" set of headers that commonly contain user credentials. It's OK to remove
     * those from the list if the downstream service is part of the same system as the
     * proxy, so they are sharing authentication data. If using a physical URL outside
     * your own domain, then generally it would be a bad idea to leak user credentials.
     */
    private Set<String> sensitiveHeaders = new LinkedHashSet<>(
            Arrays.asList("Cookie", "Set-Cookie", "Authorization"));

configure

zuul:
  sensitiveHeaders:  
  host:
    socket-timeout-millis: 60000
    connect-timeout-millis: 60000

By showing that the designation is empty, it means that the filter header list of zuul is empty, so that it can return normally.

spring read cookie method

String xxx = WebUtils.getCookie((HttpServletRequest) servletRequest,"your-cookie-name").getValue();

http://zhuanlan.51cto.com/art/201705/538644.htm

Default filtered headers

configure

Guess you like