我正在使用 SavedRequest 将用户重定向到登录后最初请求的 URL。

我得到的 url 是这样的:

public String requestedUrl(HttpServletRequest request, HttpServletResponse response) {
        SavedRequest savedRequest = new HttpSessionRequestCache().getRequest(request, response);
        if (savedRequest != null) {
            return savedRequest.getRedirectUrl();
        }
        return "";
}

我想知道是否值得检查该 URL，例如

• 基本路径与配置的应用程序基本路径相对应(出于安全原因)
• 路径没有重定向到/login 或其他一些可能导致无限重定向循环的 url

SavedRequest 是否执行与此类似的任何清理？如果是，具体是哪一个？

最佳答案

这不是答案，而是基于对代码的调查，因为我很好奇。 :3

首先让我说，了解您如何在项目中配置 Spring Security 以实际找到问题的根源会很有用。当您从 SavedRequest 追踪以查看它在 Spring Security 中的使用方式时，许多可能的途径会打开关于如何在开始时连接和配置所有内容的途径。

如前所述，紧邻SavedRequest 的代码本身非常简单，通常与问题的根源无关。您的问题的重点可以扩大:“在应用 SavedRequests 时，Spring Security 是否避免重定向到/login 的循环？”

我认为文档 10.1.4 Request Matching and HttpFirewall请解决您关于基本路径的问题:

The Servlet Specification defines several properties for the HttpServletRequest which are accessible via getter methods, and which we might want to match against. These are the contextPath, servletPath, pathInfo and queryString. Spring Security is only interested in securing paths within the application, so the contextPath is ignored.

强调我的。

在默认配置中，DefaultSavedRequest 似乎是将执行 SavedRequest根据 HttpSessionRequestCache 使用.

DefaultSavedRequest 没有经过任何广泛的处理 changes因为你最初问过你的问题。

建立它，我们可以说该类的实现相当简单，非常像 bean，并且仅限于按呈现的方式保存请求。它在构造期间不执行任何分析，除了排除某些 header (“跳过 If-Modified-Since 和 If-None-Match header ”)。

public DefaultSavedRequest(HttpServletRequest request, PortResolver portResolver) {
    Assert.notNull(request, "Request required");
    Assert.notNull(portResolver, "PortResolver required");

    // Cookies
    addCookies(request.getCookies());

    // Headers
    Enumeration<String> names = request.getHeaderNames();

    while (names.hasMoreElements()) {
        String name = names.nextElement();
        // Skip If-Modified-Since and If-None-Match header. SEC-1412, SEC-1624.
        if (HEADER_IF_MODIFIED_SINCE.equalsIgnoreCase(name)
                || HEADER_IF_NONE_MATCH.equalsIgnoreCase(name)) {
            continue;
        }
        Enumeration<String> values = request.getHeaders(name);

        while (values.hasMoreElements()) {
            this.addHeader(name, values.nextElement());
        }
    }

    // Locales
    addLocales(request.getLocales());

    // Parameters
    addParameters(request.getParameterMap());

    // Primitives
    this.method = request.getMethod();
    this.pathInfo = request.getPathInfo();
    this.queryString = request.getQueryString();
    this.requestURI = request.getRequestURI();
    this.serverPort = portResolver.getServerPort(request);
    this.requestURL = request.getRequestURL().toString();
    this.scheme = request.getScheme();
    this.serverName = request.getServerName();
    this.contextPath = request.getContextPath();
    this.servletPath = request.getServletPath();
}

addCookies、addHeader、addLocales 和 addParameters 同样简单。此类不解析请求以防止无限重定向，甚至不检查其基本路径。

因此，我们将进一步撒网，寻找另一名嫌疑人。接下来是 HttpSessionRequestCache .该 bean 可以根据您对 Spring Security 的使用情况以多种方式创建，因此事情会从那里螺旋上升 HttpConfigurationBuilder/HttpSecurity/RequestCacheConfigurer ;欢迎专家+更多信息!

关于java - Spring `SavedRequest` 是否包含任何清理逻辑以避免重定向循环或类似循环？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57099546/