Refactor `HeadersBeanDefinitionParser` and `AclImpl` to reduce the
number of nested if statements. A few extracted methods are now used
to hopefully improve readability.
Issue gh-8945
Add suppressions for existing `InterfaceIsType` violations. Ideally
theses should be classes, but we can't easily change them without
breaking binary back compatibility.
Issue gh-8945
Search and replace using '(?s)/\*\s*\* \(non-Javadoc\).*?\*/' to remove
all "(non-Javadoc)" comments. These comments used to be added
automatically by Eclipse, but are not really necessary.
Issue gh-8945
Move all inner-types so that they are consistently the last item
defined. This aligns with the style used by Spring Framework and
the consistency generally makes it easier to scan the source.
Issue gh-8945
Replace code of the form `a = b =c` with distinct statements. Although
this results in more lines of code, they are usually easier to
understand.
Issue gh-8945
Apply an Eclipse cleanup rules to ensure that fields are always accessed
using `this.`. This aligns with the style used by Spring Framework and
helps users quickly see the difference between a local and member
variable.
Issue gh-8945
Update classes that have private constructors so that they are also
declared final. In a few cases, inner-classes used private constructors
but were subclassed. These have now been changed to have package-private
constructors.
Issue gh-8945
Use '^\s+//\ \~\ .*$' and '^\s+//\ ============+$' regular expression
searches to remove superfluous comments.
Prior to this commit, many classes would have comments to indicate
blocks of code (such as constructors/methods/instance fields). These
added a lot of noise and weren't all that helpful, especially given
the outline views available in most modern IDEs.
Issue gh-8945
Having the application generate the AuthnRequest fresh allows Spring
Security to back away more gracefully. Using a Consumer implies that
the application will need to undo any values that Spring Security set
that the application doesn't want.
Also, if this does become a configuration burden, it can be simplified
in a separate ticket by exposing the default Converter.
Issue gh-8776
In several cases, taking a pre-set ValidationContext is not sufficient.
For example, the recipient is calculated via the
RelyingPartyRegistration that's currently in the context of the
request.
Instead, then, createDefaultAssertionValidator was broken up into two
different methods: One that takes no parameters and assumes the class's
default ValidationContext, and another that takes a converter to derive
the ValidationContext from the incoming authentication token.
Issue gh-8970
- Use withJwkSetUri instead of fromJwkSetUri
- Use ES512 instead of EC512
- Use NimbusReactiveOpaqueTokenIntrospector instead of NimbusOpaqueTokenIntrospector in reactive
- User authorizeExchange instead of authorizeRequests
Remove the formatter-on/formatter-off comments from Javadoc examples
so that they don't confuse checkstyle. The comments are not necessary
in the Javadoc since `pre` blocks are not formatted in the same
way as code.
Issue gh-8945
Phillip Webb
Eleftheria Stein
Rob Winch
Martin Vietz
Josh Cummings
koishikawa11