[shiro-site] branch master updated: Typo fix

[fp...@apache.org]

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 <pr...@gmail.com>
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]]#