第三章：Shiro的配置

标签：

Shiro配置基础知识

  Shiro的SecurityManager 实现及所支持的组件都是兼容JavaBean 的。这使得Shiro几乎能使用任何配置格式，如regular Java，XML(Spring, JBoss, Guice,等等)，YAML，JSON，Groovy Builder markup，以及更多的配置。

n创建SecurityManger示例

Realm r = new IniRealm();

DefaultSecurityManager s = new DefaultSecurityManager(r);

SecurityUtils.setSecurityManager(s);

 

  SecurityUtils.setSecurityManager 方法调用在一个VM 静态单例中实例化SecurityManager 实例

nSecurityManger的对象图

  SecurityManager 实现实质上是一个特定安全的嵌套组件中的模块化

对象图。因为它们也是兼容JavaBean 的，你可以调用任何嵌套组件的getter 和setter 方法来配置SecurityManager以及它的内部对象图。

  例如，如果你想配置SecurityManager 实例来使用自定义的SessionDAO 来定制Session Management，你可以通过嵌套的SessionManager 的setSessionDAO 方法直接设置SessionDAO：

SessionDAO sessionDAO = new MySessionDAO();

((DefaultSessionManager)s.getSessionManager()).setSessionDAO(sessionDAO);

 

 

ini配置的方式

nIni配置

  INI基本上是一个文本配置，包含了由唯一命名的项来 组织的键/值对。键只是每个项 唯一，而不是在整个配置中（与JDK 属性不同）

Ini配置示例：

n[main]

  配置应用程序的SecurityManager 实例及任何它的依赖组件（如Realms）的地方，示例如：

 

上述示例包括了：

1：定义对象

2：设置对象属性，如果是原始类型的值，就直接设置；如果是引用类型的值，就是用$+名称的方式来设置

3：可以使用遍历对象图的方式来设置数据

n对于Byte Array的值

  因为原始的字节数组本身不能使用文本格式，所以我们必须使用文本编码的字节数组。能够指定的值是一个Base64编码的字符串（默认），后一个16 进制编码的字符串。默认是Base64 是因为Base64 编码只需较少的文本来表示值——它拥有一个较大的编码表，意味着你的token 都是较短的。如：

如果你喜欢使用16 进制编码，你必须在字符串token 前加上0x（"zero" "x"）前缀

  对于Set 和list 而言，只需指定一组由逗号分隔的值或对象的引用。如：

对于Map，你指定一系列由逗号分隔的键-值对，每个键-值对通过冒号“:”被限定：

1：顺序问题：

INI 格式和约定都非常便捷且易于理解，但它没有其他基于text/XML 的配置机制强大。在使用上面的机制时最重要的问题是理解顺序问题，请记住：

  每个对象的实例化以及每个值的分配都是按照它们在[main] section中出现的顺序来执行的。这些配置行最终转化成一个JavaBean 的getter/setter 方法调用，因此，这些方法以同样的顺序被调用！

2：实例覆盖的问题

任何对象能够被配置中后来新定义的实例覆盖。如下

这将导致myRealm成为一个com.company.security.DatebaseRealm实例，且之前的实例将永不会被使用（同时被垃圾回收）

3：缺省的SecurityManage：

你可能已经注意到在上面的示例中，SecurityManager 实例的类并没有定义，我们仅在右边设定一个嵌套属性：

  这是因为securityManager实例是一个特殊的实例——它已经为你实例化并准备好使用，所以你不需要知道用来实例化的具体SecurityManager实例类。
  当然，如果你确实想指定你自己的实例，你可以只定义你自己的实现，如下所示：

  [users] section 允许你定义一组静态的用户帐户。这在大部分拥有少数用户帐户或用户帐户不需要在运行时被动态地创建的环境下是很有用的，比如：

  username = password, roleName1, roleName2, …, roleNameN

  仅定义非空的[users]或[roles] section 将会自动地触发org.apache.shiro.realm.text.IniRealm 实例的创建，并使它在[main] section 中可用且名为iniRealm。

  如果你不想[users] section 中密码是纯文本的，你可以使用你喜爱的散列算法（MD5，Sha1，Sha256，等等）来进行加密，并使用生产的字符串作为密码值。默认情况下，密码字符串是16 进制编码，但可以使用Base64 编码代替16进制编码来配置。

  一旦你指定了文本密码散列值，你得告诉Shiro 这些都是加密的。你可以通过配置在[main] section 中隐式地创建iniRealm 来使用合适的CredentialsMatcher 实现来对应到你所指定的哈希算法。比如在ini文件中：

[main]

sha256Matcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher

iniRealm.credentialsMatcher = $sha256Matcher

[users]

javass =355b1bbfc96725cdce8f4a2708fda310a80e6d13315aec4e5eed2a75fe8032ce,role1

  String ss = new Sha256Hash("cc").toHex();

[main]

sha256Matcher = org.apache.shiro.authc.credential.Sha256CredentialsMatcher

sha256Matcher.storedCredentialsHexEncoded=false

iniRealm.credentialsMatcher = $sha256Matcher

[users]

javass =NVsbv8lnJc3Oj0onCP2jEKgObRMxWuxOXu0qdf6AMs4=,role1

  String ss = new Sha256Hash("cc").toBase64();

  [roles] section 允许你把定义在[users] section 中的角色与权限关联起来。另外，这在大部分拥有少数用户帐户或用户帐户不需要在运行时被动态地创建的环境下是很有用的，比如：

rolename = permissionDefinition1, permissionDefinition2, …

  permissionDefinition 是一个任意的字符串，但大多数人将会使用符合org.apache.shiro.authz.permission.WildcardPermission 格式的字符串。

1：如果一个独立的permissionDefinition 需要被内部逗号分隔（例如，printer:5thFloor:print,info），你需要用户双引号环绕该定义，以避免错误解析。

2：如果角色不想关联权限，那你不需要在[roles] section 中间把他们列出来。只需定义在[user]section 中定义角色名就足以创建尚不存在的角色。

  这个放到学web的时候再讲

Shiro的Permissions

  就是用简单的字符串来表示一个权限，如：queryPrinter

1：比如：printer:print

  printer:manage 

  在这个例子中的冒号是一个特殊字符，它用来分隔权限字符串的下一部件。

  其中第一部分是权限被操作的领域（打印机），第二部分是被执行的操作。

2：多个值

  每个部件能够保护多个值。因此，除了授予用户“printer:print”和“printer:query”权限外，你可以简单地授予他们一个

  printer:print, query

3：还可以用*号代替所有的值，如：printer:* ， 当然你也可以写：*:view，表示某个用户在所有的领域都有view的权限

1：这种情况通常会使用三个部件——第一个是域，第二个是操作，第三个是被付诸实施的实例。如：printer:query:lp7200

  也可以使用通配符来定义，如：

  printer:print:*

  printer:*:*

  printer:*:lp7200

  printer:query, print:lp7200

2：部分省略：缺少的部件意味着用户可以访问所有与之匹配的值，比如：

printer:print  等价于 printer:print:*

printer  等价于 printer:*:*

但是请记住：只能从字符串的结尾处省略部件，也就是说

printer:lp7200  并不等价于 printer:*:lp7200

第三章：Shiro的配置

标签：

原文地址：http://blog.csdn.net/scholar_man/article/details/51105539