Spring Source parsing: Spring security startup details and working mode-reproduced

Original address: http://blog.csdn.net/bluishglc/article/details/12709557

spring-security boot Loading detailsThe startup of the spring-security is consistent with the start of the spring framework, starting with the loading and parsing of the XML configuration file, Spring registers its own servletcontextlistener:contextloaderlistener to listen to the ServletContext, once the ServletContext is established, Spring begins loading and parsing the configuration file, and then initializes the IOC container with the following method call: org.springframework.web.context.contextloaderlistener# Contextinitialized

->org.springframework.web.context.contextloader#initwebapplicationcontext

->org.springframework.web.context.contextloader#configureandrefreshwebapplicationcontext After Org.springframework.context.support.abstractapplicationcontext#refresh to the Refresh method, a series of substantive actions began. Two important actions of interest in this article are shown in the comments. One thing to be clear about here is that spring bean parsing and creating beans are two separate processes, A Beandefinition object (stored in Beanfactory's Beandefinitionmap) that is generated at parse time represents a lot of information about the bean instance to be created (such as the Bean's class class name, construction parameters, is singleton or prototype, etc.) used to guide the creation of beans. The created bean instances are stored in Beanfactory's Xxxxbeanmap, Xxxxsingletonobjects, and other collection fields.

each process: Load the Spring Security configuration fileThe XML configuration file that loads spring security is called by the following method

Org.springframework.web.context.contextloaderlistener#contextinitialized-> Org.springframework.web.context.contextloader#initwebapplicationcontext Org.springframework.web.context.contextloader#configureandrefreshwebapplicationcontext Org.springframework.context.support.abstractapplicationcontext#refresh

->org.springframework.context.support.abstractapplicationcontext#obtainfreshbeanfactory Org.springframework.context.support.abstractrefreshableapplicationcontext#refreshbeanfactory->org.springfra Mework.web.context.support.xmlwebapplicationcontext#loadbeandefinitions->org.springframework.beans.fact Ory.xml.xmlbeandefinitionreader#loadbeandefinitions//Starting from here to read the spring configuration file and parse it

->org.springframework.beans.factory.xml.xmlbeandefinitionreader#doloadbeandefinitions

->org.springframework.beans.factory.xml.xmlbeandefinitionreader#registerbeandefinitions

->org.springframework.beans.factory.xml.xmlbeandefinitionreader#createreadercontext

->org.springframework.beans.factory.xml.defaultbeandefinitiondocumentreader#doregisterbeandefinition S

->org.springframework.beans.factory.xml.defaultbeandefinitiondocumentreader#parsebeandefinitions

->org.springframework.beans.factory.xml.beandefinitionparserdelegate#parsecustomelement

->org.springframework.security.config.securitynamespacehandler#parse

In the Org.springframework.beans.factory.xml.beandefinitionparserdelegate#parsecustomelement method, because NamespaceURI is an HTTP ://www.springframework.org/schema/security, So use the corresponding Handler:org.springframework.security.config.SecurityNamespaceHandler to parse the configuration file. We can see from this handler parser list that all of the first-level elements under spring security correspond to the parser.



Next, the Handler.parse () method will find the corresponding parser to parse according to the current element. In our example, the current element is create the relevant filter and Filterchain (a org.springframework.security.web.DefaultSecurityFilterChain) itself。  However, the filter and Filterchain created by this method are not real instances of the corresponding class, just some place Holer (Org.springframework.beans.factory.config.RuntimeBeanReference), At the end of this method, their instances are not initialized.
second procedure: Instantiating beansOnce all the parser for the element have been parsed, an instance of the bean is created (including the filter inner beans), This process takes place in the method Org.springframework.context.support.abstractapplicationcontext#invokebeanfactorypostprocessors, As for the specific initialization process will be described in a special article, this article no longer delve into. the entry point of Spring-securityThe entire working mode of spring security is achieved by creating a filterchain of multiple filter and interceptor through the filter mechanism in the servlet. Here's how the standard spring-security embedded Web app is configured: [HTML]View Plaincopy

2. <filter>
4. <filter-name>springsecurityfilter</filter-name>
6. <filter-class>org.springframework.web.filter.delegatingfilterproxy</filter-class >
8. <init-param>
10. <param-name>targetbeanname</param-name>
12. <param-value>springsecurityfilterchain</param-value>
14. </init-param>
16. </filter>
18. <filter-mapping>
20. <filter-name>springsecurityfilter</filter-name>
22. <url-pattern>/*</url-pattern>
24. </filter-mapping>

The filter for a servlet is configured here, and the filter itself does not handle the specific request, it is actually a filter chain, which contains a list of the filter provided by multiple spring security. It is responsible for delegating the request to each filter in the list for processing. The type of this springsecurityfilterchain is: Defaultsecurityfilterchain, and most of the filter that it contains is the class provided by the spring security package, as described earlier in this article. These filter instances are spring inner beans, which are implicitly initialized by spring and managed in a container. The following is a list of the filter settings that spring has built up under some configuration:


Here are two important filter to say:   Usernamepasswordauthenticationfilter: This filter is used to authenticate user identity (authentication) when the user first logs on. The filter is only present at the time of initial authentication and will be removed from the filter chain once the authentication is passed.   Filtersecurityinterceptor: When the user is logged in successfully, each request is sent using the filter to check if the user has passed the authentication. If you pass the certification, release it, or turn to the login page. The difference between the two filter is: the first to be responsible for the initial login user check, this check needs to be based on the user's user name and password to the database check, if present, the relevant information encapsulated in a authentication object. This filter can be said to handle the authentication work at the initial login. The second filter does not need to query the database every time each filter is queried, it only needs to see whether the authentication object of the current request user is already present in the security context. This filter deals with authentication work after a successful login. This filter is required to intercept each request.

Spring Source parsing: Spring security startup details and working mode-reproduced