When Spring Security sends 302 responses to a login page we don't get
any information about the request matching in Spring MVC. Consequently
apps can end up with a lot of counter.status.302.* metrics (where
"*" can be whatever the user sent).
This change treats 3xx the same as 4xx (if it is unmapped it just gets
added to a metric called "unmapped" instead of using the actual request
path).
Fixes gh-2563
Unfortunately, we have no other choice to flip the ignoreUnknownFields
attribute of `SecurityProperties` has many different target are now set
for that namespace outside the class. See gh-3445 for a potential way
to improve that.
Closes gh-3327
If spring-hateoas is on the classpath and an MvcEndpoint returns a
@ResponseBody it will be extended and wrapped into a Resource with links.
All the existing endpoints that return sensible JSON data can be extended
this way (i.e. not /logfile). The HAL browser will also be added as an
endpoint if available on the classpath. Finally, asciidocs for the
Actuator endpoints are available as a separate jar file, which if
included in an app will also generate a new (HTTP) endpoint.
Fixes gh-1390
There is a new spring.factories entry for
org.springframework.boot.actuate.autoconfigure.EndpointWebMvcConfiguration
which loads extra beans into the MVC config for the Actuator.
If the management context is a child context all the beans go in the
child (except the Spring Security filter still). A big bonus is that
you can add WebConfigurerAdapters to configure static resources etc.
A new component called ManagementContextResolver can be used to
locate the ApplicationContext for the MVC endpoints.
Fixes gh-3345
Include support for a new <springProfile> element which can be used in
`logback-spring.xml` files to selectively enable or disable parts of the
configuration. For example:
<configuration>
...
<springProfile name="staging">
<logger name="sample.logback" level="TRACE" />
</springProfile>
...
</configuration>
Fixes gh-3338
The default is now to reveal all details unless sensitive=true
(instead of only revealing then if sensitive was explicitly false).
The definition of "secure" also changes to something more sensible
where it is only true if security is enabled.
Fixes gh-2816
This commit adds support for automatically configuring Spring Session.
In a web application when both Spring Session and Spring Data Redis
are on the classpath, Spring Session's Redis Http Session support
will be auto-configured. The max inactive interval for Redis-backed
sessions can be configured via the environment using the existing
server.session-timeout property.
Closes gh-2318
Migrate `spring.view.prefix` and `spring.view.suffix` to
`spring.mvc.view.prefix` and `spring.mvc.view.suffix` respectively. The
former properties are still handled in a backward compatible way and are
defined as deprecated in the meta-data.
Closes gh-3250
Support loading a `.spring-boot-devtools.properties` file from the
users home folder. The property file can be used to customize settings
that make sense on a per-user basis, but might not want to be checked
into the project.
Fixes gh-3151
Users can add @ExportMetric[Reader,Writer] to readers and writers that
they want to participate in the default exporter. There is also still an
@ActuatorMetricWriter that is used for the legacy (non-Java8) Gauge and
CounterServices.
The redis export and aggregate use case is a lot nicer with this
shared data between the two component types.
Also made MetricExportProperties itself a Trigger (so the default
delay etc. can be configured via spring.metrics.export.*).
Log4j2 can auto-reload its configuration file as long as the reference
to a `java.io.File` is provided in the `ConfigurationSource`. Previously,
we always created such `ConfigurationSource` with only the URL regardless
of its type.
Detect when the configuration URL points to a File and create the
`ConfigurationSource` accordingly.
The `spring-boot-sample-actuator-log4j2` has been updated to reload the
logging configuration every 30 sec if necessary.
Fixes gh-3024, gh-3030
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)
- 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
This avoids a potential problems with ordering between Dropwizard and
normal repository configuration. A Dropwizard sample has been added to
verify the behaviour.
In addition to the changes already made in 1.2.x, this commit updates
the tests in spring-boot-actuator to ensure that any Elasticsearch
data files are written into the target directory. This avoids problems
when switching branches caused by different versions of Elasticsearch
trying to read the files.
By default, Elasticsearch writes it data to ./data. This led to data
being left on the filesystem after a mvn clean which could cause
failures when moving between branches that use different versions of
Elasticsearch.
This commit updates the tests for the Elasticsearch sample and
the Elasticsearch auto-configuration classes to write the
Elasticsearch data and logs into the target directory.
This reverts commit b1c0a7cda4.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
The changes made in spring-projects/spring-framework@e403aefe cause
SampleTomcatTwoConnectorsApplication to fail to launch. The port bean,
typed as an int, is coerced into an Integer when the bean’s created. The
port() method is then called, and the proxy’s bean method interceptor
complains as it’s expecting the port bean to be an int but it’s actually
an Integer. Changing the port() bean method’s return type to Integer
works around the problem.
The versions in the dependency management for the various datastore
dependencies have been aligned with those used by Spring Data Fowler.
The Data REST tests and sample application has been updated to configure
the base path in favour of the deprecated base uri property
Closes gh-2673
Spring Framework’s ParamterizedRowMapper has been deprecated since
3.1 and has been removed in 4.2. Spring Batch currently relies on
ParameterizedRowMapper, making it incompatible with 4.2. To allow us to
build successfully against 4.2, this commit ignores Spring Boot’s tests
that use Spring Batch’s JDBC support.
See gh-2575
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
The response produced by Spring Data REST to a search that will always
return a single result, i.e. the return type is Foo rather than
List<Foo> or Page<Foo> has improved in Fowler. Previously, the response
would contain a single embedded resource. In Fowler, the response now
contains the resource that used to be embedded as a top-level resource.
This commit updates the expectations in one of the sample’s tests to
match this new behaviour.
See gh-2673
Update ElasticsearchAutoConfiguration to ensure that local nodes are
closed when the context is closed. Prior to this commit the close()
method of the Client would be called which had no effect for local
Nodes.
Fixes gh-2480
Undertow’s WebSocket client sends an illegal Origin header – it does
not include the scheme, e.g. it’ll send “localhost” rather than
“http://localhost”. This commit works around the problem by allowing
access to the SockJS endpoints from any origin, thereby disabling
OriginHandlerInterceptor’s checking of the Origin header.
Spring Integration's FileWritingMessageHandler uses a .writing file
while it's in the process of writing a message to disk and then
performs a rename (depending on the OS and filesystem this may or may
not be atommic) to create the .msg file. Prior to this commit the
test was finding the temporary .writing files and examining them. This
could lead to a FileNotFoundException being thrown as the temporary
file was deleted while the test was trying to read its contents.
This commit updates the test to only look for files with a .msg suffix
Fixes gh-2428
Dave Syer
Spring Buildmaster
Phillip Webb
Stephane Nicoll
Matt Benson
Ivan Sopov
Andy Wilkinson
Rob Baily
Eddú Meléndez
Alexander Heusingfeld
Greg Turnquist
Marcos Barbero