[ 
https://issues.apache.org/jira/browse/SHIRO-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680331#comment-17680331
 ] 

Benjamin Marwell commented on SHIRO-902:
----------------------------------------

Hah, we can't just get rid of the method as I thought.

See 
[https://shiro.apache.org/configuration.html#Configuration-INIConfiguration-Sections-roles]
 where we say:
h5. Line Format

Each line in the [roles] section must must define a role-to-permission(s) 
key/value mapping with in the following format:
{{rolename}} = {_}permissionDefinition1{_}, {_}permissionDefinition2{_}, …, 
_permissionDefinitionN_
where _permissionDefinition_ is an arbitrary String, but most people will want 
to use strings that conform to the 
[{{org.apache.shiro.authz.permission.WildcardPermission}}|https://shiro.apache.org/static/current/apidocs/org/apache/shiro/authz/permission/WildcardPermission.html]
 format for ease of use and flexibility. See the 
[Permissions|https://shiro.apache.org/permissions.html] documentation for more 
information on Permissions and how you can benefit from them.
| |Internal commas
Note that if an individual *permissionDefinition* needs to be internally 
comma-delimited (e.g. {{{}printer:5thFloor:print,info{}}}), you will need to 
surround that definition with double quotes (") to avoid parsing 
errors:`"printer:5thFloor:print,info"`|

That said,, [~ewirch], can you try to qoute the permissions?
Like so? {{PermissionUtils.resolveDelimitedPermissions("\"user:read,write:*\"", 
permissionResolver);}}

> Separator conflict between PermissionUtils.resolveDelimitedPermissions() and 
> WildcardPermission.SUBPART_DIVIDER_TOKEN
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: SHIRO-902
>                 URL: https://issues.apache.org/jira/browse/SHIRO-902
>             Project: Shiro
>          Issue Type: Bug
>          Components: Authorization (access control) 
>    Affects Versions: 1.10.1
>            Reporter: Eduard Wirch
>            Priority: Major
>
> PermissionUtils.resolveDelimitedPermissions() accepts multiple permissions, 
> separated by comma. But comma is already reserved by 
> WildcardPermission.SUBPART_DIVIDER_TOKEN.
>  
> Example: "user:read,write:*"
> Expected:
> {{parts: [}}{{  ["user"],}}{{  ["read", "write"],}}{{{}  
> ["*"]{}}}{{{}]{}}}{{{}Actual:{}}}
> {{WildcardPermission.parts: [}}{{  ["user"],}}{{{}  
> ["read"]{}}}{{{}],{}}}{{{}WildcardPermission.parts: [{}}}{{  ["write"],}}{{{} 
>  ["*"]{}}}{{{}]{}}}{{{}{}}}
> JUnit test to trigger the bug:
> {{import static org.assertj.core.api.Assertions.assertThat;}}
> {{import org.apache.shiro.authz.permission.WildcardPermission;}}
> {{import org.apache.shiro.authz.permission.WildcardPermissionResolver;}}
> {{import org.apache.shiro.util.PermissionUtils;}}
> {{import org.junit.jupiter.api.Test;}}
> {{public class PermissionUtilsTest {}}
> {{    @Test}}
> {{    void verifyResolveDelimitedPermissionsRespectsSubPartDividerToken() {}}
> {{        var permissionResolver = new WildcardPermissionResolver(true);}}
> {{        var result = 
> PermissionUtils.resolveDelimitedPermissions("user:read,write:*", 
> permissionResolver);}}
> {{        assertThat(result)}}
> {{            .containsExactlyInAnyOrder(}}
> {{                new WildcardPermission("user:read,write:*")}}
> {{            );}}
> {{    }}}
> {{}}}
>  
> I understand, that PermissionUtils actually cannot know about 
> WildcardPermission.SUBPART_DIVIDER_TOKEN, because it is hidden behind the 
> PermissionResolver abstraction. But WildcardPermissionResolver is the only 
> resolver you provide. PermissionUtils should support using it.
> I also understand that the fix will be a breaking change, which should 
> usually be avoided in public APIs. But also consider, that every new user 
> using PermissionUtils will waste time debugging this bug, and then will avoid 
> using resolveDelimitedPermissions(). What's the purpose of a stable but 
> unused API?
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to