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