When the principal of the Authentication is an object, it is not necessarily
an User: it could be another implementation of UserDetails, or even a
completely unrelated type. Since the type of the object is serialized as a
property and used by the deserialization anyway, there's no point in
enforcing a stricter type.
Not only is it more efficient without converting to an intermediate String,
using JsonNode.toString() may not even produce valid JSON according to its
Javadoc (ObjectMapper.writeValueAsString() should be used).
We have an issue where token strings that contain a colon break
the existing decoding strategy, which tokenizes on colons. so this
change urlencodes the individual tokens when creating the cookie
string; and urldecodes them decoding the cookie and extracting the
tokens. This also eliminates the need for existing code to deal with
openid tokens which contain urls, and thus colons.
Originally, if the return from getAllowFromValue(request) is "DENY",
then the X-Frame-Options header's value will proceed to be written as
"ALLOW FROM DENY" - an invalid value.
This commit adds a condition in the if clause that checks whether
allowFromValue is "DENY". This way, the X-Frame-Options header will be
written as "ALLOW FROM origin" or "DENY".
Previously DefaultSavedRequestMixinTests
serializeDefaultRequestBuildWithConstructorTest broke in Spring 5
because Spring 5's MockHttpServletRequest.setCookie now automatically adds
the Cookie header.
This commit ensures that the Cookie header is not added by overriding the
class we are writing.
Fixes gh-4272
XFrameOptionsHeaderWriter should not *add*, but *set* the
X-Frame-Options header. According to
https://tools.ietf.org/html/rfc7034#section-2.1, having
multiple values for the header is disallowed:
"There are three different values for the header field.
These values are mutually exclusive; that is, the header
field MUST be set to exactly one of the three values."
With this change, only the latest XFrameOptionsHeaderWriter
will remain.
Frank Pavageau