不展示Using default security password的解决办法:
上面解决办法解析:
上述打印的条件:
org.springframework.boot.autoconfigure.security.AuthenticationManagerConfiguration.DefaultInMemoryUserDetailsManagerConfigurer#configure
只要auth.isConfigured()成立,则就不会打印。
org.springframework.security.config.annotation.authentication.builders.AuthenticationManagerBuilder#isConfigured
因为上面的Java Config中配置了AuthenticationManager,代码逻辑就走不到打印的代码
Although the Spring suite of projects is usually easy to integrate, you might have noticed that you usually end up typing the same configuration again and again, with only a few (but important!) details changing from project to project. Teams usually end up setting a “template” configuration which they clone and adapt for every new application. Isn’t there a better way to start a Spring project?
Well yes Sir: there’s Spring Boot!
Off with the configuration chore!
The aim of Spring Boot is to get you started as easily as possible. It proposes tosetup and auto-configure your Spring-based project based on specified starter POMs and sensible default settings.
For example, have a look at this POM:
The above loads Spring Boot as the parent, then uses the four “starter” dependencies to:
- add support for web development, including Spring MVC
- support logging with the LogBack framework
- import Jetty as the engine to run your application as standalone
- add support for Spring Security
How easy was that?
Want to add support for Velocity or JPA? Just add the correct starter POM to the dependencies. Want to start writing those unit tests? Add the “test” starter POM and get JUnit, Hamcrest, Mockito and the Spring Test module all at once.
Setting up an initial, vanilla configuration for your project is as easy as:
Notice the @EnableAutoConfiguration annotation? That tells SpringBoot to try and guess the most sensible configuration based on the specified dependencies.
Agreed, that won’t take you very far. But it’s a good starting point. From here you can start overriding Spring Boot defaults in order to customize the configuration based on what you need.
There would be a lot to write about Spring Boot, and to be honest I probably just started to scratch the surface of it. I kindly invite you to check spring.io for tutorials and examples on this. Mind you, their manual is also very well written!
Enabling Spring Security on Spring Boot
In this article I want to focus on some basic Spring Security configuration when working on top of Spring Boot.
As with every other feature, spring security is added by including the matching starter POM. Just by including that POM will get you a basic configuration setup that includes HTTP Basic authentication for all material except common static resources (css, js, etc.), low-level features such as XSS and CSRF protection , and an AuthenticationManager bean with an in-memory default user created for you.
When you run your Spring Boot application as a Java Application from your IDE, you will then notice the generated default user’s password in the logs :
This is a great initial setup when you are at the very first development phases: you can now log in using “ user ” as the username and… that thing up there as the password.
Overriding the security defaults
Of course you might end up getting annoyed with this: every time you restart the application and need to log in, you need to search the generated password and copy-paste it to authenticate. Hardly practical!
Hopefully Spring Boot allows you to easily override this password generation by specifying these properties in an application.properties file located at the root of your resources (that is, src/main/resources ):
security . user . name = myOwnUser security . user . password = myOwnPassword security . user . role = ADMIN |
Restart the application and you can now log in using those credentials. That’s better!
… Although at some point you might end up needing more than one user for testing purposes. In order to do that we will need to bring in some Java configuration.
Authentication customization
In order to register more than one user, we need to build our ownAuthenticationManager configuration. The easiest way is to extend an instance of a WebSecurityConfigurerAdapter and override whatever we need, then expose that adapter as a bean.
For example, to build our own AuthenticationManager we can continue implementing the MyApp class like this:
@ ComponentScan @ EnableAutoConfiguration public class MyApp { @ Bean public WebSecurityConfigurerAdapter < strong > webSecurityConfigurerAdapter </ strong > ( ) { return < strong > new MySecurityConfigurer ( ) < / strong > ; } @ Order ( SecurityProperties . ACCESS_OVERRIDE_ORDER ) public static class MySecurityConfigurer extends WebSecurityConfigurerAdapter { < strong > @ Override < / strong > protected void < strong > configure ( AuthenticationManagerBuilder builder ) < /strong > throws Exception { builder . inMemoryAuthentication ( ) . withUser ( "user" ) . password ( "user" ) . roles ( "USER" ) . and ( ) . withUser ( "admin" ) . password ( "admin" ) . roles ( "ADMIN" ) ; } } public static void main ( String [ ] args ) { SpringApplication app = new SpringApplication ( MyApp . class ) ; app . run ( args ) ; } } |
The overridden method in the the static class exposes a builder instance which allows you to configure your users in a very straightforward manner. We use an in-memory authentication in our example, for simplicity reasons. But rest assured that you are not limited to in-memory storage for your application’s users!
When running the application again you will be able to log in using your configured users. However you will notice that the HTTP Basic authentication is gone: Spring Security now presents you a basic form to enter your credentials.
HTTP security customization
Let’s take back control of our HTTP security. In order to restore the HTTP Basic authentication, we override another configuration() method from the extended WebSecurityConfigurerAdapter :
@ Order ( SecurityProperties . ACCESS_OVERRIDE_ORDER ) public static class MySecurityConfigurer extends WebSecurityConfigurerAdapter { @ Override protected void configure ( AuthenticationManagerBuilder builder ) throws Exception{ builder . inMemoryAuthentication ( ) . withUser ( "user" ) . password ( "user" ) . roles ( "USER" ) . and ( ) . withUser ( "admin" ) . password ( "admin" ) . roles ( "ADMIN" ) ; }
< strong > @ Override < / strong > protected void < strong > configure ( HttpSecurity http ) < / strong > throwsException { http . authorizeRequests ( ) . anyRequest ( ) . authenticated ( ) . and ( ) . httpBasic( ) ; } } |
This should give us back our beloved HTTP Basic authentication.
Of course, you might probably prefer a custom implementation of a login page. This can also be done using the HttpSecurity instance exposed by that configure()method:
@ Override protected void configure ( HttpSecurity http ) throws Exception { http . authorizeRequests ( ) . < strong > antMatchers ( "/fonts/**" ) < / strong > .permitAll ( ) . anyRequest ( ) . authenticated ( ) . and ( ) . < strong > formLogin ( ) < / strong > . loginPage ( "/login.jsp" ) . permitAll( ) ; } |
The above code states that a form-based login will be enforced when authentication is needed. It will use the specified login page , which must beaccessible (permitted) to all (otherwise no one will be able to access that login page, which might be a bummer!).
So how about the rest of the chained methods?
Well, there’s a good chance that you will want your login page to be nice to look at. In order to do that, you will need for some resources to be accessible no matter what. Spring Boot makes some static resources accessible by default through Ant matchers: /css/**, /js/**, /images/** and **/favicon.ico will be permitted by default.
In the example above though, we also need access to a fonts folder which containsglyphicons used by the login page. So we specify that the default static resources, plus the content of the fonts folder specified by the ant matcher , should be permitted to all , while any other request to a resource should require authentication .
You can take it from here…
From this point on you should be able to take things into your hand by leveraging your Spring Security knowledge.
Usually the tricky part when working on top of Spring Boot is to understand what the framework provides by default and know how to override that, so that you can start using your configuration. I remember fighting Spring Boot in order to configure persistence with JPA, until I finally understood that it was all already configured for me.
Same thing goes with security: try to just override what needs to be, and let Spring Boot guide you for the rest.
…
Or if you really want to switch off the defaults entirely, you can add that@EnableWebSecurity annotation to your java configuration and take it from there. You’re the boss.
Cheers!
Like this? Why not sharing it?
http://www.tuicool.com/articles/i2YZvu