Shiro actual combat series (14) configuration

Shiro is designed to work in any environment, from the simplest command-line application to the largest enterprise cluster application. Due to the diversity of environment, many configuration mechanisms are suitable for its configuration.

1、 Many configuration options

Shiro's securitymanager implementation and supported components are JavaBean compatible. This enables Shiro to use almost any configuration format, such as regular Java, XML (spring, JBoss, Guice, etc.), yaml, JSON, groovy builder, markup, and more.

2、 Programmable configuration

The absolute easiest way to create a securitymanger and provide it to an application is to create an org. Org apache. shiro. mgt. Defaultsecuritymanager and chain it into the code.

3、 Security manager object graph

Shiro's securitymanager implementation is essentially a modular object graph in a specific security nested component. Because they are also JavaBean compatible, you can call the getter and setter methods of any nested component to configure the securitymanager and its internal object graph.

For example, if you want to configure the securitymanager instance to customize session management using custom sessiondao, you can directly set sessiondao through the setsessiondao method of the nested SessionManager:

By using direct method calls, you can configure any part of the securitymanager's object graph.

However, stylized customization is too simple to represent the ideal configuration of most real-world applications. Here are some reasons why stylized customization may not be suitable for you:  it requires you to understand and instantiate a direct implementation. This will be better if you don't need to know the specific implementations and where to find them.  due to the type security of Java, you need to convert the objects obtained through the get * method to get their specific implementation. So many transformations are ugly, lengthy, and tie you closely to the implementation class.

SecurityUtils. The setsecuritymanager method call instantiates the securitymanager instance in a VM static singleton. The VM static singleton not only brings benefits to many applications, but also causes some problems. If multiple Shiro enabled applications run in the same JVM. It would be nice if the instance were an application singleton rather than a static memory reference.  whenever you want to change Shiro configuration, it requires you to recompile your application. However, even with so many warnings, direct programming methods are still valuable in memory constrained environments, such as smartphone applications. If your application does not run in a memory constrained environment, you will find that text-based configuration is easier to use and read.

4、 Ini configuration

Instead, most applications benefit from text-based configuration, can modify the source code independently, and even make it easier for those unfamiliar with Shiro's API to understand.

In order to ensure that a common text-based standard configuration mechanism can work with minimal third-party dependency in all environments, Shiro supports ini format to build securitymanager object graph and its supported components. Ini is easy to read, easy to configure, and simple to set up, suitable for most applications.

(1) Security manager from ini instance

If you need, ini configuration can also be through org apache. shiro. config. The ini class is created programmatically. The function of ini class is the same as that of JDK Java util. The properties class is similar, but it also supports segmentation through the section name.

Now that we know how to build a securitymanager from the INI configuration, let's see how to define a Shiro ini configuration.

（2) INI Sections

Ini is basically a text configuration that contains key / value pairs organized by uniquely named sections. The key is only unique for each section, not in the entire configuration (different from the JDK attribute). However, each section can be regarded as a single attribute definition. Comment lines can be defined with hash characters (# - i.e. "hash", "pound" or "number" symbols) or semicolons (";") Start.

The following is an example of Shiro's understanding of a section:

[main]

[main] section is the securitymanager instance of your configuration application and any of its dependent components (such as realms). Configuring object instances, such as securitymanager or any of its dependent components, sounds difficult by using ini. We can only use name / value pairs. But with a little Convention and understanding of object diagrams, you will find that you can do a lot of things. Shiro uses these conditions to provide a simple but quite concise configuration mechanism. We often like to call this method "poor people's" dependency injection. Although it is not as powerful as the fully mature spring / Guice / JBoss XML file, you will find that it can accomplish many things without too much complexity. Of course, those other configuration mechanisms are also available, but they are not necessary to use Shiro.

To arouse your desire, here is an example of an effective [main] configuration. We will discuss its details below, but you may find that you can understand a lot of things intuitively:

This line instantiates com company. shiro. realm. A new object instance of myrealm type and make the object use the myrealm name for further reference and configuration. If the instantiated object implements org apache. shiro. util. Nameable interface, then nameable The setname method will be called on the object with that name (myrealm in this case).

be careful:

The instantiation of each object and the assignment of each value are performed in the order in which they appear in the [main] section. These configuration lines are eventually converted into getter / setter method calls of a JavaBean, so these methods are called in the same order! Keep this in mind when you write your configuration.

[users]

The [users] section allows you to define a set of static user accounts. This is useful in most environments where there are a few user accounts or user accounts do not need to be created dynamically at run time. Here is an example:

a.Automatic IniRealm :

Defining only non empty [users] or [roles] sections will automatically trigger org apache. shiro. realm. text. Create an instance of inirealm and make it available in the [main] section and named inirealm. You can configure it like other objects described above.

b.Line Format

Each line in the [users] section must be in the following format:

username = password,roleName1,roleName2,…,roleNameN 

The value to the left of the equal sign is the user name.

The first value to the right of the equal sign is the user's password, which is required. 

Any comma separated value after the password is the role name assigned to the user. The role name is optional.

c.Encrypting Passwords

If you don't want the password in the [users] section to be plain text, you can use your favorite hash algorithm (MD5, SHA1, sha256, etc.) to encrypt and use the produced string as the password value. By default, the password string is hexadecimal encoding, but you can use Base64 encoding instead of hexadecimal encoding to configure (see below).

Once you specify the text password hash value, you have to tell Shiro that these are encrypted. You can configure to implicitly create inirealm in the [main] section to use the appropriate credentialsmatcher implementation to correspond to the hash algorithm you specify:

Like any other object, you can configure any property on the credentialsmatcher to reflect your hash policy, for example, specify whether salting is used or how many hash iterations need to be performed. See org apache. shiro. authc. credential. Hashedcredentials matcher's Javadoc to better understand hashing strategies if they may be useful to you.

For example, if your user password string is Base64 encoded instead of the default hexadecimal, you can specify the description:

[roles]

The [roles] section allows you to associate roles defined in the [users] section with permissions. In addition, this is useful in most environments where there are a few user accounts or user accounts do not need to be created dynamically at run time. Here is an example:

Line Format

In the [roles] section, each configuration line must define a key / value mapping roles to permissions in the following format: rolename = permissiondefinition1, permissiondefinition2, permissiondefinitionn. Permissiondefinition is an arbitrary string, but most people will use it in accordance with org apache. shiro. authz. permission. String in wildcardpermission format for ease of use and flexibility. See the permissions documentation for more information about permissions and how you can benefit from them.

Internal commas

Please note that if an independent permissiondefinition needs to be separated by an internal comma (for example, printer: 5thfloor: print, info), you need the user to surround the definition with double quotes to avoid incorrect parsing: "printer: 5thfloor: print, info"

Roles without Permissions

If you have roles that don't need permission Association, you don't need to list them in the [roles] section, if you don't want to. Just defining the role name in the [user] section is enough to create a role that does not yet exist.