Prefer dispatcher context for authorize tag beans

[wonderfulrosemari]

Closes gh-8843

When both root and child web application contexts are present, JSP authorize
tags should resolve security beans from the DispatcherServlet context used for
the current request.

Previously, AbstractAuthorizeTag always resolved beans from
findRequiredWebApplicationContext(servletContext), which prefers the root
context. If security beans were defined only in the child context, this could
cause failures like missing WebSecurityExpressionHandler.

Changes include:

• resolve application context from the current request's DispatcherServlet
  context attribute when available
• fall back to SecurityWebApplicationContextUtils.findRequiredWebApplicationContext
  when no dispatcher context is present
• add regression coverage for root+child context setup to ensure
  <sec:authorize> expression evaluation succeeds

[jzheaux]

Thanks, @wonderfulrosemari, for the PR! I've left feedback inline.

[jzheaux]

Let's please make this public so it's clear that Spring Security expects applications to set this attribute themselves. WebAttributes is a good home for this. Please also take a look at the naming convention used in WebAttributes for both the name and the value.

[jzheaux]

Additionally, it doesn't seem to me that what is being retrieved here is the dispatcher servlet's context, per se. The point of Rob's suggestion is to decouple the application context from its source. Thus, a better name might be APPLICATION_CONTEXT_ATTRIBUTE.

[jzheaux]

At this point in the code, we aren't sure what it is, so perhaps value is a better variable name.

[jzheaux]

Instead of silently falling back, let's please error if the attribute is being misused:

if (value == null) {
    return SecurityWebApplicationContextUtils.findRequiredWebApplicationContext(getServletContext());
}
if (value instanceof ApplicationContext context) {
    return context;
}
throw new IllegalArgumentException("WebAttributes.APPLICATION_CONTEXT_ATTRIBUTE value must be of type ApplicationContext, found type " + value.getClass());

The reason for this is to alert the application developer to the misconfiguration as early as possible.

[jzheaux]

Please remove the dispatcher-specific language in this test.

[jzheaux]

Please add a test to confirm an error if the attribute is not of type ApplicationContext.

[jzheaux]

Please verify here that the mocked context was the one that was used.

[jzheaux]

The name here seems to indicate that we would only expect looking up the "dispatcher context" when the "root context" is present. However, the logic you are adding is about using the WebAttribute-based Application Context when one is specified. Will you please adjust the name?