This commit introduces a new OriginHandshakeInterceptor. It filters
Origin header value against a list of allowed origins.
AbstractSockJsService as been modified to:
- Reject CORS requests with forbidden origins
- Disable transport types that does not support CORS when an origin
check is required
- Use the Origin request header value instead of "*" for
Access-Control-Allow-Origin response header value
(mandatory when Access-Control-Allow-Credentials=true)
- Return CORS header only if the request contains an Origin header
It is possible to configure easily this behavior thanks to JavaConfig API
WebSocketHandlerRegistration#addAllowedOrigins(String...) and
StompWebSocketEndpointRegistration#addAllowedOrigins(String...).
It is also possible to configure it using the websocket XML namespace.
Please notice that this commit does not change the default behavior:
cross origin requests are still enabled by default.
Issues: SPR-12226
These changes provide more robust handling of function
reference compilation in SpEL expressions. Prior to
this change the isCompilable check was not performing
enough visibility checks on the proposed target
function, causing bytecode to be generated that
would lead to an IllegalAccessError.
The changes also bring the argument handling for
function invocation completely inline with that used
for method invocation allowing some code to be deleted.
Many new tests are also included for function
reference compilation.
Issue: SPR-12359
Before this change the simple broker simply removed subscriptions
upon receiving a DISCONNECT message assuming it was a result of
a client STOMP WebSocket session ending.
However, if the server-side application sends a DISCONNECT to
the broker in order to terminate a session, the STOMP WebSocket
session could remain unware without any further action. This
change ensures the simple broker sends a DISCONNECT_ACK message
downstream whenever it receives a DISCONNECT.
Issue: SPR-12288
With SPR-9293, it is now possible to HTML escape text while taking into
account the current response encoding. When using UTF-* encodings, only
XML markup significant characters are escaped, since UTF-* natively
support those characters.
This commit adds a new servlet context parameter to enable this fix by
default in a Spring MVC application:
<context-param>
<param-name>responseEncodedHtmlEscape</param-name>
<param-value>true</param-value>
</context-param>
Issue: SPR-12350, SPR-12132
This commits complements 222d2b1 for another required dependency.
javax.persistence.Entity was previously required, regardless of which
aspects were actually used by the project. It is now optional and will
not break the build if it is not present. Note that the side effect is that
AnnotationDrivenStaticEntityMockingControl is disabled as well if the
JPA API is not available.
Issue: SPR-6819
Prior to this commit, a project using compile time weaving upgrading to
4.1 was forced to add spring-context-support and the jcache API in order
to build. This problem is not new really: spring-aspects holds all
aspects provided by the framework and they all are evaluated when
compiling. 4.1 just happens to define a new aspect that requires extra
dependencies.
This commit uses a new annotation of AspectJ 1.8.3. When @RequiredTypes
is added on an aspect, it is evaluated only if the classes defined on the
annotation are actually present. If they are not, the aspect is disabled
and does not break the build.
Issue: SPR-12163
This change adds a ChannelInterceptor that flips the immutable flag on
messages being sent. This allows components sending messages to leave
the message mutable for interceptors to further apply modifications
before the message is sent (and exposed to concurrency).
The interceptor is automatically added with the STOMP/WebSocket Java
and XML config and the StompSubProtocolHandler leaves parsed incoming
messages mutable so they can be further modified before being sent.
Issue: SPR-12321
During the HTTP Content Negotiation phase, the ContentNegotiationManager
uses configured ContentNegotiationStrategy(ies) to define the list of
content types accepted by the client.
When HTTP clients don't send Accept headers, nor use a configured
file extension in the request, nor a request param, developers can
define a default content type using the
ContentNegotiationConfigurer.defaultContentType() method.
This change adds a new overloaded defaultContentType method that takes a
ContentNegotiationStrategy as an argument. This strategy will take the
current request as an argument and return a default content type.
Issue: SPR-12286
Building on the initial work for SPR-12326, this commit
addresses three problems:
Firstly the ReflectiveMethodResolver is modified to consider
a direct parameter match more important than a varargs match.
Also in that same type when there are a number of close
matches, the first one is taken rather than the last one.
Secondly more testcases and better support have been added
for the case of passing a single parameter to a varargs
accepting method.
Finally it is possible to set the root context object
indirectly and not pass it on getValue() calls to the
expression objects but not all variants of getValue()
were handling that. This is now fixed.
Issue: SPR-12326
This commit adds new htmlEscape methods that take the character encoding
as a parameter. According to specs and recommendations, the list of
chars to be html escaped depends on the encoding used in the response.
If the current char encoding supports chars natively, we shouldn't
escape those; of course, reserved chars (<,>,',",&) should always be
escaped.
See: http://www.w3.org/TR/html4/sgml/entities.html#h-24.3
See: spring-projects/spring-framework#385 by @candrews
Issue: SPR-9293
