Update ManagementSecurityAutoConfiguration so that MVC Endpoints that
have Principal arguments are not treated in any special way. This
restores Spring Boot 1.1.x behavior where the 'sensitive' flag is used
to determine access rules.
The HealthMvcEndpoint still uses the Principal (when available) to
determine if full status information can be displayed. It now also
explicitly checks the environment for `endpoints.health.sensitive`
to determine if the user has opted-out and requires complete health
details.
The health MVC endpoint should now work as follows:
* Default configuration - No login is required, full information is only
displayed if a Principal is available.
* endpoints.health.sensitive=true - Login is required, full information
is displayed.
* endpoints.health.sensitive=false - Login is not required, full
information is displayed.
Fixes gh-2211
Shares the /health endpoint request mapping between security config
and MVC dispatcher. Generalizes so that instead of a marker
interface (AnonymouslyAccessibleMvcEndpoint), an MvcEndpoint
signals that it wants to control its own access rules by adding
a Principal to the @RequestMapping method parameters (more @MVC).
Fixes gh-2015 slightly differently
The changes in 3bb598a overload the health endpoint's sensitive
property such that it's now considered sensitive if management
security is enabled. When an endpoint is sensitive anonymous
access is prevented. This breaks the health endpoint which should
return a filtered view of the server's health when it's accessed
anonymously rather than rejecting the request.
This commit introduces AnonymouslyAccessibleMvcEndpoint, a marker
extension of the MvcEndpoint interface. It is implemented by
HealthMvcEndpoint. ManagementSecurityAutoConfiguration has been
updated to allow anonymous access to endpoints that aren't sensitive
or that implement AnonymouslyAccessibleMvcEndpoint.
Fixes gh-2015
Including maps and lists. Beans with no metadata (in
/META-INF/*spring-configuration-metadata.json) are just serialized
as they come (so might have problems like cycles). Serialization
errors are caught and rendered as an "error" for that bean. Any
problems can be fixed by preparing metadata and specifying which
properties are to be rendered that way.
Fixes gh-1746, fixes gh-1921
The http.mappers.* configuration properties assumed that the mapping
was JSON (on of the property names was jsonPrettyPrint) and also only
exposed a small subset of the configuration options supported by
Jackson (and GSON). The property names implied that it would configure
all HTTP mapping, however it was ignored by GsonAutoConfiguration.
This commit deprecates the support for http.mappers.* in favour of
configuring Jackson or Gson instead. Jackson can be configured
declaratively using the spring.jackson.* properties or programtically.
Gson can be configured programatically by using a GsonBuilder to
create a Gson instance with the desired configuration.
gh-1946 has been opened to add support for declarative configuration
of Gson.
Closes gh-1945
It *is* very useful to have filtering on by default, so that is now
the case (in spring-boot-starter-parent). Users can filter resources
by default by adding @*@ placeholders (so as not to clash with Spring
${} placeholders).
Fixes gh-1199
Then we can optionally find a non-anonymous principal if there
is one. If the user is anonymous then the health result is cached
up to endpoints.health.ttl (default 1000ms) to prevent a DOS attack.
Fixes gh-1353
If the actuator endpoints are configured on a different port then there
are some settings in the main ServerProperties that we would like to
re-use (e.g. the access log). The easiest way to do that is to just
configure the management server using the same ServerProperties instance
and then overwrite the things that are different (and stored in
ManagementServerProperties).
Fixes gh-1581
The request is being made to '/' and, while the application does have
a mapping for '/', that mapping is not looked for before Spring
Security's filter rejects the request with a 401. This means that the
request is considered to be unmapped and this is reflected in the
metric's name.
See #1331 and #1333
when server.servletPath is set we need to add prefixes to
the security filter paths, and the /error path.
Conflicts:
spring-boot-actuator/src/main/java/org/springframework/boot/actuate/autoconfigure/ManagementSecurityAutoConfiguration.java
With this commit the state of a component or subsystem becomes a first-class citizen in Boot's application health support. HealthIndicators now return a Health instance with status and some contextual details.
An aggregation strategy has been introduced to aggregate several Health instances into one final application Health instance. Out of the box OrderedHealthAggregator can be configured to allow different ordering or a custom HealthAggregator bean can be registered.
We now have a much simpler DataSourceAutoConfiguration that binds to whatever
DataSource concrete type it finds at runtime. To be able to quickly switch between
Hikari and the other types of DataSource there's a minute shim for translating
the common properties (username, password, url, driverClassName), but actually
only url is different. The shim and also DataSource initialization is supported
through DataSourceProperties, but the other native properties get bound directly
through the concrete runtime type of the DataSource.
The /configprops endpoint works (and is exposed in the actuator sample).
Fixes gh-840, fixes gh-477, see also gh-808.
Since Spring supports gobal error handling through
@ControllerAdvice, it is quite easy to set up more meta-data
about an exception for the BasicErrorController. You need
to be careful not to swallow Security exceptions, and probably
others (optionally) so this feature needs a bit more work.
See gh-538
Spring Security doesn't know that Spring MVC maps /foo, /foo.json
and /foo/ all to the same handler. This change explicitly adds
suffixes to the actuator endpoint matchers so they are properly
protected.
Rename the RestTemplates to TestRestTemplate to help indicate that it's
primarily intended for testing. Also now extend RestTemplate to allow
direct use, rather than via factory methods.
Fixes gh-599
Makes them a lot more readable IMO, and also enables @Autowiring
from the context into the test case (sweeet). I added @DirtiesContext
to all of them as well to be on the safe side, but possbly that can be
optimized in some way as well.
The management.contextPath property should now be respected in a
secure application, whether or not the management.port is different.
Added some test cases in the sample to verify.
Fixes gh-469
Long package names are really unnecessary in samples and they
just clutter things up. Also Spring Loaded doesn't work with
org.sfw packages, so to demo that technology you need a
different package name.
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
When management endpoints are on a different port the HandlerMappings
are restricted to a single EndpointHandlerMapping, so the error
controller (which is a normal @Controller with @RequestMappings) does
not get mapped.
Fixed by addinga shim Endpoint on "/error" that delegates to the
ErrorController (which interface picks up an extra method).
Phillip Webb
Andy Wilkinson
Dave Syer
Phillip Webb
Dave Syer
Christian Dupuis