spring security原理图及其解释（3）
spring security原理图及其解释（三）
What is spring_security_login and how did we get here?
You may have noticed that when you attempted to hit the home page of our JBCP Pets store, you were redirected to the URL http://localhost:8080/JBCPPets/ spring_security_login
The spring_security_login portion of the URL represents a default login page as named in the DefaultLoginPageGeneratingFilter class. We can use configuration attributes to adjust the name of this page to be something unique to our application.
Let's look at the HTML source of this form (stripping out table layout information) to figure out what the UsernamePasswordAuthenticationFilter is expecting:
<form name='f' action='/JBCPPets/j_spring_security_check' method='POST'>
User:<input type='text' name='j_username' value=''>
Password:<input type='password' name='j_password'/>
<input name="submit" type="submit"/>
<input name="reset" type="reset"/>
</form>
As our application is not utilizing the security component of our host servlet container, we could explicitly configure the UsernamePasswordAuthenticationFilter to expect form fields with different names. This particular configuration change is more complicated than you might expect; so for now, we'll trace back the lineage of UsernamePasswordAuthenticationFilter to see how it arrived in our configuration in the first place
The UsernamePasswordAuthenticationFilter is configured through the use of the <form-login> sub-element of the <http> configuration directive. As we mentioned earlier in this chapter, the auto-config attribute that we set will automatically add <form-login> capability to your application if you haven't explicitly included the directive. As you may guess, the j_spring_security_check URL doesn't map to anything physical in our application. This is a special URL that is watched for by the UsernamePasswordAuthenticationFilter to handle form-based login. In fact, there are several of these special URLs that cover specific global behavior in Spring Security. You'll find a table of these URLs in Appendix, Additional Reference Material.
Where do the user's credentials get validated?
In our simple three-step configuration file, we used an in-memory credential store to get up and running quickly:
<authentication-manager alias="authenticationManager">
<authentication-provider>
<user-service>
<user authorities="ROLE_USER" name="guest" password="guest"/>
</user-service>
</authentication-provider>
</authentication-manager>
We didn't wire this AuthenticationProvider to any explicit implementation, and we see once again that the security namespace handler performs a lot of rote configuration work on our behalf. Remember that the default implementation of the AuthenticationManager supports configuration of one or more AuthenticationProvider implementations. The <authentication-provider> declaration will by default instantiate an out of the box implementation known as o.s.s.authentication.dao.DaoAuthenticationProvider. The declaration of the <authentication-provider> element will also automatically wire this AuthenticationProvider to the configured (or, in our case, automatically configured) AuthenticationManager.
AuthenticationProvider虽然没有指定实现类，但是系统默认为我们指定了。而且默认的AuthenticationManager实现支持一个或者多个AuthenticationProvider。<authentication-provider>默认声明一个箱外的实现DaoAuthenticationProvider，用它来声明的会自动装配到AuthentiacationManager里面。
The DaoAuthenticationProvider is an AuthenticationProvider that provides a thin wrapper to implement the AuthenticationProvider interface and then delegates to an implementation of the o.s.s.core.userdetails. UserDetailsService interface. The UserDetailsService is responsible for returning an implementation of o.s.s.core.userdetails.UserDetails.
DaoAuthenticationProvider是一种AuthenticationProvider并且提供了一层AuthenticationProvider接口的简单实现，它代理UserDetailsService的实现。UserDetailsService 负责返回一个UserDetails的实现。
If you review the Javadoc for UserDetails, you'll notice that it looks strikingly similar to the Authentication interface we reviewed earlier. Don't get confused, although they have a lot of overlap in method names and capabilities, they have quite different purposes:
如果你重新看javadoc来查看UserDetails，你会发现它和接口Authentication非常相似。不要搞混了，虽然他们有很多重复的方法名和容器，但是他们有不同的目的：
Our declaration of the <user-service> subelement triggered a configuration of the o.s.s.core.userdetails.memory.InMemoryDaoImpl implementation of the UserDetailsService. As you'd anticipate, this implementation stores the users configured in the XML security configuration file in a memory-resident data store. The configuration of this service supports other attributes allowing accounts to be disabled or locked as well.
Let's visually review how the components of the DaoAuthenticationProvider interact to provide authentication support to the AuthenticationManager:
What is spring_security_login and how did we get here?
You may have noticed that when you attempted to hit the home page of our JBCP Pets store, you were redirected to the URL http://localhost:8080/JBCPPets/ spring_security_login
The spring_security_login portion of the URL represents a default login page as named in the DefaultLoginPageGeneratingFilter class. We can use configuration attributes to adjust the name of this page to be something unique to our application.
Let's look at the HTML source of this form (stripping out table layout information) to figure out what the UsernamePasswordAuthenticationFilter is expecting:
<form name='f' action='/JBCPPets/j_spring_security_check' method='POST'>
User:<input type='text' name='j_username' value=''>
Password:<input type='password' name='j_password'/>
<input name="submit" type="submit"/>
<input name="reset" type="reset"/>
</form>
As our application is not utilizing the security component of our host servlet container, we could explicitly configure the UsernamePasswordAuthenticationFilter to expect form fields with different names. This particular configuration change is more complicated than you might expect; so for now, we'll trace back the lineage of UsernamePasswordAuthenticationFilter to see how it arrived in our configuration in the first place
The UsernamePasswordAuthenticationFilter is configured through the use of the <form-login> sub-element of the <http> configuration directive. As we mentioned earlier in this chapter, the auto-config attribute that we set will automatically add <form-login> capability to your application if you haven't explicitly included the directive. As you may guess, the j_spring_security_check URL doesn't map to anything physical in our application. This is a special URL that is watched for by the UsernamePasswordAuthenticationFilter to handle form-based login. In fact, there are several of these special URLs that cover specific global behavior in Spring Security. You'll find a table of these URLs in Appendix, Additional Reference Material.
Where do the user's credentials get validated?
In our simple three-step configuration file, we used an in-memory credential store to get up and running quickly:
<authentication-manager alias="authenticationManager">
<authentication-provider>
<user-service>
<user authorities="ROLE_USER" name="guest" password="guest"/>
</user-service>
</authentication-provider>
</authentication-manager>
We didn't wire this AuthenticationProvider to any explicit implementation, and we see once again that the security namespace handler performs a lot of rote configuration work on our behalf. Remember that the default implementation of the AuthenticationManager supports configuration of one or more AuthenticationProvider implementations. The <authentication-provider> declaration will by default instantiate an out of the box implementation known as o.s.s.authentication.dao.DaoAuthenticationProvider. The declaration of the <authentication-provider> element will also automatically wire this AuthenticationProvider to the configured (or, in our case, automatically configured) AuthenticationManager.
AuthenticationProvider虽然没有指定实现类，但是系统默认为我们指定了。而且默认的AuthenticationManager实现支持一个或者多个AuthenticationProvider。<authentication-provider>默认声明一个箱外的实现DaoAuthenticationProvider，用它来声明的会自动装配到AuthentiacationManager里面。
The DaoAuthenticationProvider is an AuthenticationProvider that provides a thin wrapper to implement the AuthenticationProvider interface and then delegates to an implementation of the o.s.s.core.userdetails. UserDetailsService interface. The UserDetailsService is responsible for returning an implementation of o.s.s.core.userdetails.UserDetails.
DaoAuthenticationProvider是一种AuthenticationProvider并且提供了一层AuthenticationProvider接口的简单实现，它代理UserDetailsService的实现。UserDetailsService 负责返回一个UserDetails的实现。
If you review the Javadoc for UserDetails, you'll notice that it looks strikingly similar to the Authentication interface we reviewed earlier. Don't get confused, although they have a lot of overlap in method names and capabilities, they have quite different purposes:
如果你重新看javadoc来查看UserDetails，你会发现它和接口Authentication非常相似。不要搞混了，虽然他们有很多重复的方法名和容器，但是他们有不同的目的：
Our declaration of the <user-service> subelement triggered a configuration of the o.s.s.core.userdetails.memory.InMemoryDaoImpl implementation of the UserDetailsService. As you'd anticipate, this implementation stores the users configured in the XML security configuration file in a memory-resident data store. The configuration of this service supports other attributes allowing accounts to be disabled or locked as well.
Let's visually review how the components of the DaoAuthenticationProvider interact to provide authentication support to the AuthenticationManager: