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

Benjamin Marwell commented on SHIRO-629:
----------------------------------------

Hi [~pkriens],

we believe the user (developer of the app) must check that the inputs are from 
trusted sources. A check in shiro might do more harm than good.

Other than that, we would be happy to see an example of expected and actual 
outputs, preferrably as a junit test (e.g. test with {{abc*def}} and what it 
matches against, but shouldn't).

For the performance: Yes, a lot of objects are being created, but we never saw 
a bottleneck here which came to our attention. A hash-based caching strategy 
might be possible. If the numbers are reasonable that a caching strategy might 
be reasonable, we will happily consider it. Did you perform any performance 
tests we could use as a basis?

Thanks for your insights!

Ben

> WildcardPermission syntax
> -------------------------
>
>                 Key: SHIRO-629
>                 URL: https://issues.apache.org/jira/browse/SHIRO-629
>             Project: Shiro
>          Issue Type: Question
>          Components: Authorization (access control) 
>            Reporter: Peter Kriens
>            Priority: Critical
>
> While looking at the WildcardPermission I see it allows a much wider range of 
> usage then used in all the examples I've seen. Looking at the implementation 
> I notice it is not verifying. I also noted that there is no escaping for 
> matching the [*:,] tokens in the target permission. I think the examples 
> follow the grammar like:
>       permission ::= part ( ':' part ) *
>       part            ::= wildcard | options
>       wildcard     ::= '*'
>       options      ::= literal ( ',' literal )
>       literal         ::= [^*:,]+
> This should disallow permissions like "abc*def", "abc:def,*:foo", "abc:", 
> "x:::::::::::::::". However, the implementation seems to more or less allow 
> anything without warnings or errors. Is this intentional?
> Last, the implementation looks quite expensive since it requires for each 
> construction numerous lists, sets, and arrays. It also executes n*m a regular 
> expression operations for the split. Since the target permission could be 
> constructed frequently since it contains the parameters this is imho very 
> costly. 
> Therefore it would be nice if a formal grammar including the character set 
> and escaping.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to