This is an automated email from the ASF dual-hosted git repository.
fpapon pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shiro-site.git
The following commit(s) were added to refs/heads/master by this push:
new 058ed1b Typo fix
new 3ff6e55 Merge pull request #42 from prashantpandey10/patch-1
058ed1b is described below
commit 058ed1bda427c104657aab08ad166d517a25ed14
Author: Prashant R Pandey <[email protected]>
AuthorDate: Wed Feb 6 16:34:54 2019 +0530
Typo fix
Changed capabilities spelling
---
java-authorization-guide.md.vtl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java-authorization-guide.md.vtl b/java-authorization-guide.md.vtl
index a6a12df..167e73b 100644
--- a/java-authorization-guide.md.vtl
+++ b/java-authorization-guide.md.vtl
@@ -139,7 +139,7 @@ if(currentUser.isPermitted(perm)){
You can construct the permission string the way you want so long as your
[Realm](realm.html "Realm") knows how to work with it. In this example we use
Shiro's optional permission syntax, [WildCardPermissions](permissions.html
"Permissions"). WildCardPermissions are powerful and intuitive. If you'd like
to learn more about them then check out the [Permissions
Documentation](static/current/apidocs/org/apache/shiro/authz/Permission.html).
-With string-based permission checks, you get the same functionality as the
example before. The benefit is that you are not forced to implement a
permission interface and you can construct the permission via a simple string.
The downside is that you don't have type safety and if you needed more
complicated permission capabilitues that are outside the scope of what this
represents, you're going to want to implement your own permission objects based
on the permission interface.
+With string-based permission checks, you get the same functionality as the
example before. The benefit is that you are not forced to implement a
permission interface and you can construct the permission via a simple string.
The downside is that you don't have type safety and if you needed more
complicated permission capabilities that are outside the scope of what this
represents, you're going to want to implement your own permission objects based
on the permission interface.
<a name="JavaAuthorizationGuide-AnnotationAuthorization"></a>
#[[###Annotation Authorization]]#
