将Shiro集成到任何Web应用程序中的最简单的方法是在web.xml中配置Servlet ContextListener和Filter,了解如何读取Shiro的INI配置。大部分INI配置格式本身在配置页面的INI Sections部分中定义,但我们将在此处介绍一些其他特定于Web的部分。
使用Spring?Spring Framework用户不会执行此设置。如果你使用Spring,你将需要阅读关于Spring特定的web配置。
在Shiro 1.2及更高版本中,标准Web应用程序通过添加以下XML块来初始化Shiro web.xml
:
<listener>
<listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
</listener>
...
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ShiroFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
这假设一个Shiro INI 配置文件位于以下两个位置之一,使用以前找到的位置:
/WEB-INF/shiro.ini
shiro.ini
文件在类路径的根。这里是上面的配置:
的EnvironmentLoaderListener
初始化四郎WebEnvironment
实例(包含一切四郎需要操作,包括SecurityManager
),并使其在访问ServletContext
。如果您需要随时获取此WebEnvironment
实例,则可以调用WebUtils.getRequiredWebEnvironment(servletContext)
。
该ShiroFilter
会利用这个WebEnvironment
来执行所有必要的安全操作的任何过滤的要求。
最后,该filter-mapping
定义确保所有请求都被过滤ShiroFilter
,建议大多数Web应用程序使用,以确保任何请求都是安全的。
通常希望在任何其他“filter-mapping”声明之前定义“ShiroFilter filter-mapping”,以确保Shiro也能在这些过滤器中运行。
WebEnvironment
类默认情况下,EnvironmentLoaderListener
将创建一个IniWebEnvironment
实例,它承担Shiro的基于INI的配置。如果愿意,您可以WebEnvironment
通过在ServletContext
context-param
中指定一个自定义实例来指定web.xml
:
<context-param>
<param-name>shiroEnvironmentClass</param-name>
<param-value>com.foo.bar.shiro.MyWebEnvironment</param-value>
</context-param>
这允许您自定义如何解析配置格式并将其表示为WebEnvironment
实例。您可以对现有IniWebEnvironment
的自定义行为进行子类化,或者完全支持不同的配置格式。例如,如果有人想要在XML而不是INI中配置Shiro,他们可以创建一个基于XML的实现,例如com.foo.bar.shiro.XmlWebEnvironment
。
本IniWebEnvironment
类希望读取并加载INI配置文件。默认情况下,此类将自动查找以下两个位置的Shiro .ini
配置(按顺序):
/WEB-INF/shiro.ini
classpath:shiro.ini
它将使用先找到的。
然而,如果你希望将你的配置在其他位置,则可能与另一指定位置context-param
在web.xml
:
<context-param>
<param-name>shiroConfigLocations</param-name>
<param-value>YOUR_RESOURCE_LOCATION_HERE</param-value>
</context-param>
默认情况下,param-value
期望由ServletContext.getResource
方法定义的规则可解析。例如,/WEB-INF/some/path/shiro.ini
但是,您也可以使用Shiro的ResourceUtils类支持的适当资源前缀来指定特定的文件系统,类路径或URL位置,例如:
file:/home/foobar/myapp/shiro.ini
classpath:com/foo/bar/shiro.ini
url:http://confighost.mycompany.com/myapp/shiro.ini
在1.1或更早版本的Web应用程序中启用Shiro的最简单的方法是定义IniShiroFilter并指定filter-mapping
:
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.IniShiroFilter</filter-class>
</filter>
...
<!-- Make sure any request you want accessible to Shiro is filtered. /* catches all -->
<!-- requests. Usually this filter mapping is defined first (before all others) to -->
<!-- ensure that Shiro works in subsequent filters in the filter chain: -->
<filter-mapping>
<filter-name>ShiroFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
此定义要求您的INI配置位于类路径(例如classpath:shiro.ini
)的根目录下的shiro.ini文件中。
如果不想将INI配置放入/WEB-INF/shiro.ini
或classpath:shiro.ini
,您可以根据需要指定自定义资源位置。添加configPath init-param
并指定资源位置:
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.IniShiroFilter</filter-class>
<init-param>
<param-name>configPath</param-name>
<param-value>/WEB-INF/anotherFile.ini</param-value>
</init-param>
</filter>
...
未限定(无限额或“非前缀”)configPath
值被假定为ServletContext
资源路径,可通过该
ServletContext.getResource
方法定义的规则解析。
ServletContext资源路径在Shiro 1.2和更高版本中可用。在1.1和更早的版本中,所有configPath
的定义必须指定classpath:
,file:
或url:
前缀。
你也可以指定其他非ServletContext
使用资源位置classpath:
,url:
或file:
前缀分别表示classpath中,URL或文件系统位置。例如:
...
<init-param>
<param-name>configPath</param-name>
<param-value>url:http://configHost/myApp/shiro.ini</param-value>
</init-param>
...
最后,还可以将INI配置嵌入到web.xml中,而不使用INI文件。您可以使用config init-param
而不是configPath
:
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.IniShiroFilter</filter-class>
<init-param><param-name>config</param-name><param-value>
# INI Config Here
</param-value></init-param>
</filter>
...
直列配置往往细小型或简单的应用,但它通常是更方便的外部化它的原因如下专用shiro.ini文件:
这取决于你 - 使用什么对你的项目有意义。
除了标准[main]
,[users]
并[roles]
在主已经说明部分配置章节中,你还可以指定一个特定的网络[urls]
在部分shiro.ini
文件:
# [main], [users] and [roles] above here
...
[urls]
...
该[urls]
部分允许你做一些事情,不以任何Web框架存在,我们见过的:确定特设的过滤器链在应用程序中任何匹配的URL路径的能力!
这是远远比你通常定义过滤链更灵活,功能强大,简洁的web.xml
:即使你从未使用过任何其他的功能,该功能提供四郎也只有这个使用,仅此一项就使值得使用。
该urls
节中每行的格式如下:
_URL_Ant_Path_Expression_ = _Path_Specific_Filter_Chain_
例如:
...
[urls]
/index.html = anon
/user/create = anon
/user/** = authc
/admin/** = authc, roles[administrator]
/rest/** = authc, rest
/remoting/rpc/** = authc, perms["remote:invoke"]
接下来,我们将详细介绍这些行的含义。
等号(=)左侧的令牌是相对于Web应用程序的上下文根的Ant样式路径表达式。
例如,假设您有以下[urls]
行:
/account/** = ssl, authc
该行指出:“以我的应用程序的路径的任何请求/account
或任何它的子路径(/account/foo
,/account/bar/baz
,等),将触发”SSL,authc'过滤器链“。我们将在下面介绍过滤链。
请注意,所有路径表达式都与应用程序的上下文根相关。这意味着如果你部署你的应用程序一天,www.somehost.com/myapp
然后,然后将其部署到www.anotherhost.com
(没有'myapp'子路径),模式匹配仍然会工作。所有路径都是相对于HttpServletRequest.getContextPath()值。
URL路径表达式根据传入请求按照它们定义的顺序和第一个匹配的WINS进行评估。例如,让我们假设有以下链定义:
/account/** = ssl, authc
/account/signup = anon
如果传入的请求打算到达/account/signup/index.html
(所有“anon'ymous用户可访问),它将永远不会被处理!。原因是该/account/**
模式首先匹配传入请求,并将所有剩余定义“短路”。
始终记住根据FIRST MATCH WINS策略定义您的过滤器链!
等号(=)右侧的令牌是以逗号分隔的过滤器列表,以对匹配该路径的请求执行。它必须匹配以下格式:
filter1[optional_config1], filter2[optional_config2], ..., filterN[optional_configN]
哪里:
[main]
部分中定义的过滤器bean的名称[optional_configN]
是一个可选的括号字符串,对于该特定路径(每个过滤器,特定于路径的配置!)的特定过滤器具有含义。如果过滤器不需要为该URL路径指定特定的配置,您可以丢弃括号,filterN[]
只是变成了filterN
。并且因为过滤器令牌定义链(aka List),记住顺序很重要!按您希望请求流过链的顺序定义逗号分隔的列表。
最后,如果不满足其必要条件(例如,执行重定向,使用HTTP错误代码进行响应,直接呈现等),则每个过滤器都可以自由地处理响应。否则,预期允许请求通过链继续到最终目的地视图。
小费能够对路径特定配置(即[optional_configN]
过滤器令牌的一部分)做出反应是对于Shiro过滤器可用的独特特征。
如果你想创建自己的javax.servlet.Filter
实现,也可以这样做,请确保你的过滤器子类org.apache.shiro.web.filter.PathMatchingFilter
可用于过滤器链定义的“池”过滤器在此[main]
部分中定义。在主节中分配给它们的名称是在过滤器链定义中使用的名称。例如:
[main]
...
myFilter = com.company.web.some.FilterImplementation
myFilter.property1 = value1
...
[urls]
...
/some/path/** = myFilter
当运行Web应用程序时,Shiro将创建一些有用的默认Filter
实例,并使其在[main]
部分自动可用。您可以像配置main
其他bean一样配置它们,并在链定义中引用它们。例如:
[main]
...
# Notice how we didn't define the class for the FormAuthenticationFilter ('authc') - it is instantiated and available already:
authc.loginUrl = /login.jsp
...
[urls]
...
# make sure the end-user is authenticated. If not, redirect to the 'authc.loginUrl' above,
# and after successful authentication, redirect them back to the original account page they
# were trying to view:
/account/** = authc
...
自动可用的默认Filter实例由DefaultFilter枚举定义,枚举的name
字段是可用于配置的名称。他们是:
过滤器名称 | 类 |
---|---|
anon | org.apache.shiro.web.filter.authc.AnonymousFilter |
authc | org.apache.shiro.web.filter.authc.FormAuthenticationFilter |
authcBasic | org.apache.shiro.web.filter.authc.BasicHttpAuthenticationFilter |
登出 | org.apache.shiro.web.filter.authc.LogoutFilter |
noSessionCreation | org.apache.shiro.web.filter.session.NoSessionCreationFilter |
烫发 | org.apache.shiro.web.filter.authz.PermissionsAuthorizationFilter |
港口 | org.apache.shiro.web.filter.authz.PortFilter |
休息 | org.apache.shiro.web.filter.authz.HttpMethodPermissionFilter |
角色 | org.apache.shiro.web.filter.authz.RolesAuthorizationFilter |
ssl | org.apache.shiro.web.filter.authz.SslFilter |
用户 | org.apache.shiro.web.filter.authc.UserFilter |
与任何过滤器链定义机制(web.xml
,Shiro的INI等)的情况一样,只需通过将过滤器包含在过滤器链定义中来启用它,并通过从链定义中删除它来禁用它。
但是在Shiro 1.2中添加的一个新功能是能够启用或禁用过滤器,而不从过滤器链中删除它们。如果启用(默认设置),则会按预期对请求进行过滤。如果禁用,则过滤器将允许请求立即传递到中的下一个元素FilterChain
。您可以通常基于配置属性触发过滤器的启用状态,或者甚至可以根据请求触发它。
这是一个强大的概念,因为与更改静态过滤器链定义(这将是永久和不灵活的)相比,基于某些要求启用或禁用过滤器通常更方便。
Shiro通过其OncePerRequestFilter抽象父类完成此操作。所有Shiro的开箱即用的Filter实现子类化这一个,因此可以启用或禁用,而不从过滤器链中删除它们。你可以为你自己的过滤器实现子类这个类,如果你也需要这个功能*。
* SHIRO-224希望能为任何过滤器启用此功能,而不只是那些子类OncePerRequestFilter
。如果这对您很重要,请投票支持此问题。
该OncePerRequestFilter(及其所有子类)支持启用/所有的请求,以及在每个请求的基础禁用。
对所有请求的一般启用或禁用过滤器是通过将其enabled
属性设置为true或false来实现的。默认设置是true
因为大多数过滤器本身需要执行,如果它们在链中配置。
例如,在shiro.ini中:
[main]
...
# configure Shiro's default 'ssl' filter to be disabled while testing:
ssl.enabled = false
[urls]
...
/some/path = ssl, authc
/another/path = ssl, roles[admin]
...
此示例显示可能许多URL路径都可能要求请求必须由SSL连接保护。在开发过程中设置SSL可能会令人沮丧和耗时。在开发过程中,可以禁用ssl过滤器。部署到生产时,您可以使用一个配置属性启用它 - 这比手动更改所有URL路径或维护两个Shiro配置要容易得多。
OncePerRequestFilter
实际上根据其isEnabled(request, response)
方法确定是否启用或禁用过滤器。
此方法默认返回属性的值,enabled
用于一般启用/禁用所有请求,如上所述。如果要根据请求特定条件启用或禁用过滤器,则可以覆盖该OncePerRequestFilter
isEnabled(request,response)
方法以执行更具体的检查。
Shiro的PathMatchingFilter(一个子类)OncePerRequestFilter
能够基于被过滤的特定路径对配置做出反应,这意味着除了传入的请求和响应之外,您还可以基于路径和特定于路径的配置启用或禁用过滤器。
如果您需要能够对匹配路径和路径特定配置做出反应,以确定是启用还是禁用过滤器,而不是OncePerRequestFilter
isEnabled(request,response)
覆盖方法,那么您将覆盖该PathMatchingFilter
isEnabled(request,response,path,pathConfig)
方法。
在Web环境中,Shiro的默认会话管理器SessionManager
实现是ServletContainerSessionManager
。这个非常简单的实现将所有会话管理职责(包括如果servlet容器支持它的会话群集)委托给运行时Servlet容器。它本质上是一个桥梁,用于Shiro的会话API到servlet容器,没有别的。
使用此默认值的一个好处是,使用现有servlet容器会话配置(超时,任何容器特定的集群机制等)的应用程序将按预期工作。
这个默认的缺点是,你绑定到servlet容器的特定会话行为。例如,如果您想集群会话,但在生产中使用Jetty进行测试和Tomcat,则容器特定的配置(或代码)将不可移植。
如果使用默认的servlet容器支持,您可以在Web应用程序的web.xml
文件中按预期配置会话超时。例如:
<session-config>
<!-- web.xml expects the session timeout in minutes: -->
<session-timeout>30</session-timeout>
</session-config>
如果希望您的会话配置设置和集群在servlet容器(例如Jetty在测试中,但是Tomcat或JBoss在生产中)是可移植的,或者您想要控制特定的会话/集群功能,您可以启用Shiro的本地会话管理。
“Native”这个词意味着Shiro自己的企业会话管理实现将用于支持所有Subject
和HttpServletRequest
会话,并完全绕过servlet容器。但是放心 - Shiro直接实现了Servlet规范的相关部分,所以任何现有的web / http相关代码如预期一样工作,并且不需要“知道”Shiro是透明地管理会话。
要为Web应用程序启用本机会话管理,您需要配置一个本地的Web会话管理器来覆盖默认的基于servlet容器的会话管理器。你可以通过配置DefaultWebSessionManager
Shiro的实例来实现SecurityManager
。例如,在shiro.ini
:
shiro.ini本地Web会话管理
[main]
...
sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
# configure properties (like session timeout) here if desired
# Use the configured native session manager:
securityManager.sessionManager = $sessionManager
一旦声明,您可以配置DefaultWebSessionManager
实例与本地会话选项,如会话超时和聚类配置,如会话管理部分所述。
配置DefaultWebSessionManager
实例后,按会话管理:会话超时中所述配置会话超时
在DefaultWebSessionManager
支持两个特定网络的配置属性:
sessionIdCookieEnabled
(布尔)sessionIdCookie
,一个Cookie实例。该sessionIdCookie
属性本质上是一个模板 - 您配置Cookie
实例属性,并且此模板将用于在运行时使用适当的会话ID值设置实际的HTTP Cookie。
DefaultWebSessionManager的sessionIdCookie
默认实例是a SimpleCookie
。这个简单的实现允许对要在http Cookie上配置的所有相关属性进行JavaBeans风格的属性配置。
例如,您可以设置Cookie域:
[main]
...
securityManager.sessionManager.sessionIdCookie.domain = foo.com
有关其他属性,请参阅SimpleCookie JavaDoc。
cookie的默认名称JSESSIONID
与servlet规范一致。此外,Shiro的cookie支持HttpOnly
标志。该sessionIdCookie
套HttpOnly
到true
默认情况下,额外的安全性。
Shiro的Cookie
概念HttpOnly
甚至在Servlet 2.4和2.5环境中支持该标志(而Servlet API只在2.6或更高版本中支持它)。
如果您不想使用会话Cookie,可以通过将sessionIdCookieEnabled
属性配置为false 来禁用它们。例如:
禁用本机会话Cookie
[main]
...
securityManager.sessionManager.sessionIdCookieEnabled = false
Shiro将执行'rememberMe'服务,如果AuthenticationToken
实现的org.apache.shiro.authc.RememberMeAuthenticationToken
接口。此接口指定一个方法:
boolean isRememberMe();
如果此方法返回true
,则Shiro将记住会话中的最终用户身份。
常用的UsernamePasswordToken
已经实现了RememberMeAuthenticationToken
接口并支持rememberMe登录。
要以程序方式使用rememberMe,可以将值设置为true
支持此配置的类。例如,使用标准UsernamePasswordToken
:
UsernamePasswordToken token = new UsernamePasswordToken(username, password);
token.setRememberMe(true);
SecurityUtils.getSubject().login(token);
...
对于Web应用程序,authc
过滤器默认为a FormAuthenticationFilter
。这支持将“rememberMe”布尔作为form / request参数读取。默认情况下,它期望请求参数被命名rememberMe
。这里是一个示例shiro.ini配置支持这:
[main]
authc.loginUrl = /login.jsp
[urls]
# your login form page here:
login.jsp = authc
在您的网络表单中,有一个名为“rememberMe”的复选框:
<form ...>
Username: <input type="text" name="username"/> <br/>
Password: <input type="password" name="password"/>
...
<input type="checkbox" name="rememberMe" value="true"/>Remember Me?
...
</form>
默认情况下,FormAuthenticationFilter
会寻找名为请求参数username
,password
和rememberMe
。如果这些不同于您在表单中使用的表单字段名称,则需要在上配置名称FormAuthenticationFilter
。例如,在shiro.ini
:
[main]
...
authc.loginUrl = /whatever.jsp
authc.usernameParam = somethingOtherThanUsername
authc.passwordParam = somethingOtherThanPassword
authc.rememberMeParam = somethingOtherThanRememberMe
...
您可以rememberMe
通过设置默认的{{RememberMeManager}}的各种cookie属性来配置cookie的功能。例如,在shiro.ini中:
[main]
...
securityManager.rememberMeManager.cookie.name = foo
securityManager.rememberMeManager.cookie.maxAge = blah
...
请参阅CookieRememberMeManager
和支持SimpleCookie
JavaDoc的配置属性。
RememberMeManager
应该注意的是,如果默认的基于cookie的实现RememberMeManager
不能满足你的需要,你可以插入任何你喜欢的securityManager
类似,你将配置任何其他对象引用:
[main]
...
rememberMeManager = com.my.impl.RememberMeManager
securityManager.rememberMeManager = $rememberMeManager
Apache Shiro提供了一个Subject
-aware JSP / GSP标签库,允许您根据当前主题的状态控制您的JSP,JSTL或GSP页面输出。这对于基于查看网页的当前用户的身份和授权状态来个性化视图是非常有用的。
标签库描述符(TLD)文件捆绑在shiro-web.jar
中META-INF/shiro.tld
文件。要使用任何标记,请将以下行添加到JSP页面的顶部(或在您定义页面指令的任何位置):
<%@ taglib prefix="shiro" uri="http://shiro.apache.org/tags" %>
我们使用shiro
前缀来指示shiro标签库命名空间,但是您可以分配任何您喜欢的名称。
现在,我们将介绍每个标记,并说明如何使用它来呈现网页。
guest
标签guest
只有当前Subject
被视为“访客”时,标记才会显示其包装内容。客人是Subject
没有身份的任何人。也就是说,我们不知道用户是谁,因为他们没有登录,他们不记得(从记住我服务)从以前的网站访问。
例:
<shiro:guest>
Hi there! Please <a href="login.jsp">Login</a> or <a href="signup.jsp">Signup</a> today!
</shiro:guest>
该guest
标签是的逻辑相反的user
标记。
user
标签user
仅当当前Subject
被视为“用户”时,标记才会显示其包装内容。在此上下文中的“用户”被定义为Subject
具有已知标识,或者来自成功认证或者来自“记住我”服务。请注意,此标记在语义上与已认证的标记不同,后者比此标记更受限制。
例:
<shiro:user>
Welcome back John! Not John? Click <a href="login.jsp">here<a> to login.
</shiro:user>
该user
标签是的逻辑相反的guest
标记。
authenticated
标签仅当当前用户在其当前会话期间已成功通过身份验证时,才显示主体内容。它比“用户”标签限制性更强。它在逻辑上与“notAuthenticated”标签相反。
该authenticated
标签将显示其包裹内容仅在当前Subject
已成功验证了当前会话中。这是一个比用户更严格的标签,用于保证敏感工作流中的身份。
例:
<shiro:authenticated>
<a href="updateAccount.jsp">Update your contact information</a>.
</shiro:authenticated>
该authenticated
标签是的逻辑相反的notAuthenticated
标记。
notAuthenticated
标签该notAuthenticated
如果当前标签将显示其包裹内容Subject
已不还成功地在本届会议期间进行身份验证。
例:
<shiro:notAuthenticated>
Please <a href="login.jsp">login</a> in order to update your credit card information.
</shiro:notAuthenticated>
该notAuthenticated
标签是的逻辑相反的authenticated
标记。
principal
标签该principal
标签将输出主题的principal
(标识属性)或本金的属性。
没有任何标记属性,标记将呈现toString()
主体的值。例如(假设主体是字符串用户名):
Hello, <shiro:principal/>, how are you today?
这是(大多数)等价于以下:
Hello, <%= SecurityUtils.getSubject().getPrincipal().toString() %>, how are you today?
该principal
标签假设默认情况下,该校长印的是subject.getPrincipal()
价值。但是如果要打印一个不是主要主体的值,而是在主体的{ principal集合中另一个值,那么您可以通过类型获取该主体,并打印该值。
例如,打印主题的用户ID(而不是用户名),假设ID在主体集合中:
User ID: <principal type="java.lang.Integer"/>
这是(大多数)等价于以下:
User ID: <%= SecurityUtils.getSubject().getPrincipals().oneByType(Integer.class).toString() %>
但是如果主体(上面的默认主要主体或者“类型化”主体)是一个复杂对象而不是一个简单的字符串,并且你想引用该主体上的一个属性呢?您可以使用该property
属性指示要读取的属性的名称(必须通过JavaBeans兼容的getter方法访问)。例如(假设主要主体是User对象):
Hello, <shiro:principal property="firstName"/>, how are you today?
这是(大多数)等价于以下:
Hello, <%= SecurityUtils.getSubject().getPrincipal().getFirstName().toString() %>, how are you today?
或者,结合type属性:
Hello, <shiro:principal type="com.foo.User" property="firstName"/>, how are you today?
这在很大程度上等同于以下:
Hello, <%= SecurityUtils.getSubject().getPrincipals().oneByType(com.foo.User.class).getFirstName().toString() %>, how are you today?
hasRole
标签hasRole
仅当当前Subject
分配了指定的角色时,标记才会显示其包装内容。
例如:
<shiro:hasRole name="administrator">
<a href="admin.jsp">Administer the system</a>
</shiro:hasRole>
该hasRole
标签是的逻辑相反lacksRole标记。
lacksRole
标签lacksRole
仅当当前Subject
未分配指定角色时,标记才会显示其包装内容。
例如:
<shiro:lacksRole name="administrator">
Sorry, you are not allowed to administer the system.
</shiro:lacksRole>
该lacksRole
标签是的逻辑相反hasRole标记。
hasAnyRole
标签该hasAnyRole
如果当前标签将显示其包裹内容Subject
被分配任何指定的角色从一个逗号分隔的角色名称列表。
例如:
<shiro:hasAnyRoles name="developer, project manager, administrator">
You are either a developer, project manager, or administrator.
</shiro:lacksRole>
该hasAnyRole
标签目前还没有一个逻辑相反的标记。
hasPermission
标签hasPermission
只有当前的Subject
“has”(暗示)指定的权限,标签才会显示其包装的内容。也就是说,用户具有指定的能力。
例如:
<shiro:hasPermission name="user:create">
<a href="createUser.jsp">Create a new User</a>
</shiro:hasPermission>
该hasPermission
标签是的逻辑相反lacksPermission标记。
lacksPermission
标签lacksPermission
只有当前的Subject
DOES没有(暗示)指定的权限,标签才会显示其包装的内容。也就是说,用户没有指定的能力。
例如:
<shiro:lacksPermission name="user:delete">
Sorry, you are not allowed to delete user accounts.
</shiro:hasPermission>
该lacksPermission
标签是的逻辑相反hasPermission标记。
虽然我们希望本文档帮助您与Apache Shiro正在进行的工作,社区正在不断改进和扩展文档。如果您希望帮助Shiro项目,请考虑更正,扩展或添加您需要的文档。你提供的每一点帮助扩大了社区,反过来又改善了Shiro。
提交文档的最简单方法是通过点击以下Edit
链接提交拉取请求,将其发送到用户论坛或用户邮件列表。
https://www.leftso.com/article/123.html