[ 
https://issues.apache.org/jira/browse/SHIRO-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Demers updated SHIRO-59:
------------------------------

    Attachment: SHIRO-59.diff

My other thought was to add a new method to the PermissionResolver interface, 
but that seems like mixing apples and oranges.

{code}
/**
     * Resolves a Collection of Permissions based on the given String 
representation.
     * 
     * @param roleString the String representation of a role name to resolve.
     * @return
     */
    Collection<Permission> resolvePermissionsInRole(String roleString);
{code}

> Refactor Realm implementations to favor delegation over inheritance
> -------------------------------------------------------------------
>
>                 Key: SHIRO-59
>                 URL: https://issues.apache.org/jira/browse/SHIRO-59
>             Project: Shiro
>          Issue Type: Improvement
>            Reporter: Les Hazlewood
>         Attachments: SHIRO-59.diff
>
>
> Currently most people need to subclass Realm implementations to perform role 
> and/or permission checks.  This is not very scalable when more than a few 
> realms exist, or people need to re-use realms across applications.
> Instead, it would be much nicer to allow developers to configure components 
> that did most of the common Realm logic, regardless of data store.  For 
> example, perhaps a RolePermissionResolver could be introduced:
> rolePermissionResolver.getPermissions( String roleName );
> This could be injected across multiple realms across applications instead of 
> needing to subclass Realm implementations - a little nicer approach.  Also, 
> we might want to look at uses of the Strategy design pattern for checking 
> logic.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to