Shiro actual combat series (15): Spring integration Shiro

Shiro's JavaBean compatibility makes it ideal for using spring XML or other spring based configuration mechanisms. The Shiro application requires an application with a single instance of securitymanager. Note that this will not be a static singleton, but there should be only one instance that the application can use, whether it is a static singleton or not.

Web Applications

Shiro has state-of-the-art support for spring web applications. In web applications, all Shiro accessible requests do not have to pass through a major Shiro filter. The filter itself is extremely powerful, allowing temporary custom filter chains to be executed based on any URL path expression. Before Shiro 1.0, you had to use a hybrid approach in spring web applications to define Shiro filters and all of them on the web XML, but securitymanager is defined in spring XML. This is somewhat frustrating because you can't fix your configuration in one place and use the configuration capabilities of more advanced spring functions, such as propertyplaceholderconfigurer or abstract beans, to fix common configurations. Now in Shiro 1.0 and later versions, all Shiro configurations are completed in spring XML to provide a more robust spring configuration mechanism. Here is how to configure Shiro in a spring based web application:

web. xml

Among other things, spring web Elements in XML (contextloaderlistener, log4jconfiglistener, etc.) define the following filters and filter mappings:

applicationContext. XML in your ApplicationContext In the XML file, the securitymanager and 'shirofilter' beans that define web support will be used by the web XML reference

Enabling Shiro Annotations

In standalone and web applications, You may want to use Shiro's annotations for security checking (for example, @ requiresroles, @ requirespermissions, etc.). This requires Shiro's spring AOP integration to scan the appropriate annotation classes and execute the necessary security logic. Here's how to use these annotations. Just add these two bean definitions to applicationcontext.xml:

Secure Spring Remoting

Shiro's spring remote support has two parts: configuring client remote calls and configuring server to receive and process remote calls.

Server-side Configuration 、

When a remote calling method reaches the Shiro enabled server, the subject associated with the RPC call must be bound to the accessed receiving thread during thread execution. This is done in ApplicationContext This is done by defining the secureremoteinvocationexecution bean in the XML

After you define this bean, you must insert it into any remote exporter you are using to export / expose your service. The exporter implementation is defined according to the remoting mechanism / protocol used. See the remoting section of spring for information on defining exporter beans. For example, if you use HTTP based remote invocation (note the related properties of the secureremoteinvocationexecution bean):

Client-side Configuration

After the remote call is executed, the identification information of the subject must be attached to the load of the remote call to make the server know who made the call. If the client is a spring based client, the association is completed through Shiro's secureremoteinvocationfactory:

After you define this bean, you need to insert it into the spring remoting proxyfactory bean based on the specific protocol you are using. For example, if you are using HTTP based remote invocation (note the related properties of the secureremoteinvocationfactory bean defined above):