[
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.