There was too much state really in the old implementation of
AuthenticationManagerConfiguration, and it was leading occasionally
to null pointers when method A assumed that method B had already
been called and it hadn't. This change manages to concentrate all the
references to an AuthenticationManagerBuilder into a single method
call, removoing the need for storing it at all.
Fixes gh-1556
It needs to run as soon as the DataSource is available really otherwise
anything else that depends on the DataSource (like Security JDBC
initializers) might fail when it tries to use it.
One change from 1.1.1 is that if you have a schema.sql you had better
make sure your data.sql talks to the same tables. In 1.1.1 you could
sometimes get away with letting Hibernate initialize the tables for
your data.sql and *also* have a schema.sql. This was fragile and doomed
to fail eventually if the DataSourceInitializer somehow got
initialized earlier (e.g. through a @DependsOn), so in the spririt
of honesty being the best policy we explicitly disallow it now.
Fixes gh-1115
There were some residual issues to do with the changes to the implementation
of security.basic.enabled=false. It was a good idea to have a filetr chain
triggered by the flag being off because it smooths the way for user-defined
filter chains to use the Boot AuthenticationManager (as a first step at least),
but it wasn't a goog idea to add any actual secuity features to that filter.
E.g. if it has HSTS then even an app like Sagan that has some secure endpoints
that it manages itself and the rest is unsecured has issues because it can't
accept connections over HTTP even on unsecure endpoints.
TODO: find a way for security.ssl_enabled=true to apply to only the user-
defined security filter (maybe not possible or worth the effort, since they
can inject a SecurityProperties if they need it?).
See gh-928
Actually the web-secure sample is misusing
security.basic.enabled=false (IMO) - it should be a flag
to say that you want to temporarily disable the basic security
fallback on application endpoins, not way to disable all
security autoconfiguration.
Added test case to web-secure sample to ensure a user
can log in.
Fixes gh-979
For the convenience of users who want to selectively override the
access rules in an application without taking complete control of the
security configuration we now have some constants:
* SecurityProperties.ACCESS_OVERRIDE_ORDER for overriding just the
application endpoint access rules
* ManagementServerProperties.ACCESS_OVERRIDE_ORDER for overriding the
application endpoint and management endpoint access rules
Fixes gh-803
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
If the user explicitly disables the basic security features and forgets to
@EnableWebSecurity, and yet still wants a bean of type
WebSecurityConfigurerAdapter, he is trying to use a custom
security setup and the app would fail in a confusing way without
this change.
Fixes gh-568
If the user sets security.basic.enabled=false he has to remember
to @EnableWebSecurity. Possibly we could be more helpful about the
exception, but I think this might be pilot error.
Fixes gh-568
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.
Use org.springframework.boot instead of ${project.groupId}
groupId in order to make it easier to use spring-boot-samples
modules as a starting point for new projects.
Spring Buildmaster
Rob Baily
Phillip Webb
Dave Syer
Stephane Nicoll
Phillip Webb
Dave Syer
Javier Gayoso
Sebastien Deleuze