User can enable OAuth2 SSO by declaring the intent (@EnableOAuth2Sso)
and also configuring the client properties (spring.oauth2.client.*).
The spring.oauth2.sso.* are only needed to change the path for the
login (defaults to /login) - any other security configuration for the
protected resources can be added in a WebSecurityConfigurerAdapter
which carries the @EnableOAuth2Sso annotation.
* Automatically spin up Authorization Server and Resource Server
* Automatically configures method level security included OAuth2Expression handler
* Wrote extensive unit tests verifying default behavior as well as the auto-configuration backing off when custom Authorization/Resource servers are included
* Created org.springframework.boot.security.oauth2 subpackage to contain it
* Can also disable either resource of authorization server completely with a single property for each
* Print out the auto-generated secrets and other settings
* Added spring-boot-sample-secure-oauth2 to provide a sample that can be run and poked with curl as well as some automated tests.
* Make users ask for which servers to install by adding @Enable*
* User has to @EnableGlobalMethodSecurity instead of using properties files
Add Spring Security OAuth2 support to Spring Boot CLI
* Triggered from either @EnableAuthorizationServer or @EnableResourceServer
* Needs to have @EnableGlobalMethodSecurity to allow picking the annotation model.
* By default, comes with import support for @PreAuthorize, @PreFilter, @PostAuthorize, and @PostFilter via a single start import
* Also need import support for the enable annotations mentioned above.
* Added extra test case and sample (oauth2.groovy)
Previously, to use a custom SpringApplicationBuilder subclass in
SpringBootServletInitializer, it was necessary to either override
createRootApplicationContext or configure and duplicate the logic
that configures the builder with initializers, the context class, etc.
This commit introduces a new method, createSpringApplicationBuilder,
that can be overridden to use a custom builder without having to
duplicate any configuration logic.
Closes gh-2694
- Apply project’s code formatting and conventions
- Don’t use the IO and worker thread configuration when creating the
worker for the AccessLogReceiver. The IO and worker thread
configuration is for HTTP request processing and a worker in its
default configuration should be sufficient for the access log
receiver.
- Don’t use a temporary directory as the default for the access log
directory. A temporary directory makes (some) sense for Tomcat as it
requires a directory for its basedir. Undertow has no such
requirement and using a temporary directory makes it hard to locate
the logs. The default has been updated to a directory named logs,
created in the current working directory.
- Document the new properties in the application properties appendix
Closes gh-3014
This commit adds support for configuring Undertow's access log via the
environment using the following properties:
server.undertow.access-log-enabled
server.undertow.access-log-pattern
server.undertow.access-log-dir
See gh-3014
Previously, JacksonAutoConfiguration would register any Jackson Module
beans with every ObjectMapper found in the application context. This
was not consistent with the rest of the Jackson auto-configuration,
which is only applied to ObjectMappers that are created or configured
via the auto-configured Jackson2ObjectMapperBuilder.
This commit removes the code that registers Jackson Module beans with
every ObjectMapper. Such beans will still be registered with
ObjectMappers created or configured using the auto-configured
Jackson2ObjectMapperBuilder. This aligns the configuration of Module
with the rest of the ObjectMapper configuration and makes it possible
for users to create an ObjectMapper bean and still have complete control
over the modules that are registered with it.
Closes gh-2489
A recent change to the internals of RequestMappingHandlerMapping
broke to Spring Mobile-related tests as they were using reflection
to verify that the configuration had been applied correctly.
This commit makes the tests more robust by using the Java API to
access the interceptors for a request and verify that the expected
interceptor is present. To further simplify the tests, the unnecessary
use of an embedded servlet container factory has also been removed.
- Verify that isReady has been called
- When forking, use a random port for JMX
- Don’t wait for application termination as it introduces a race
condition and verifying that shutdown has been requested is
sufficient
See gh-2525
Users that wish to override the version of Hibernate need to override
the hibernate.version property, as it’s the one used when declaring the
dependency management for Hibernate’s modules, so the
hibernate-entitymanager.version property is of little value.
Closes gh-3004
SpringApplicationLifecycle provides basic lifecycle operations on the
current Spring Boot application (that is checking if the application has
fully started and gracefully terminate the app). It can be registered as
an MBean of the platform MBean server if a specific property is set.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
Write to NUL on Windows and /dev/null on other platforms. Increase the
default number of iterations to avoid problems with the reduced timing
precision on Windows.
Closes gh-2976
izeye
Dave Syer
Greg Turnquist
Stephane Nicoll
Andy Wilkinson
Marcos Barbero
Joe Kutner
Eddú Meléndez