[jira] [Comment Edited] (SHIRO-530) INI parser does not properly handled backslashes at end of values

["atomicknight (Jira)" <ji...@apache.org>]

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

atomicknight edited comment on SHIRO-530 at 3/29/20, 3:09 PM:
--------------------------------------------------------------

Hi [~bmarwell],

First off, sorry for the poor bug report - it really should have included a test case to demonstrate what the perceived issue was.

It's been many years since I've worked with Shiro, but I think this issue was intended to describe that there was (is?) no way to specify a value that ends in a backslash (e.g. specifying the prefix for user principals in the Microsoft format of "DOMAIN\principal").

Here's a partial test case added to IniTest#testSplitKeyValue that fails:
{code:java}
        test = "Truth=Beauty\\\\";
        kv = Ini.Section.splitKeyValue(test);
        assertEquals("Truth", kv[0]);
        assertEquals("Beauty\\", kv[1]);
{code}
The additional escaping of backslashes within string literals can be confusing, so here's what it was intended to convey. In the INI file:
{code:java}
Truth=Beauty\\
{code}
And the expected value:
{code:java}
Beauty\
{code}
Instead, the actual value is:
{code:java}
Beauty
{code}
This seems to suggest a different (but related?) issue, which is that Ini#splitKeyValue doesn't understand a literal backslash anywhere in a key-value definition (when encountering a backslash character, it doesn't consider whether the previous character was also a backslash, so it just discards both characters). So this also fails:
{code:java}
        test = "Truth=Beau\\\\ty";
        kv = Ini.Section.splitKeyValue(test);
        assertEquals("Truth", kv[0]);
        assertEquals("Beau\\ty", kv[1]);
{code}
Sorry again for the vague description.

 


was (Author: atomicknight):
Hi [~bmarwell],

First off, sorry for the poor bug report - it really should have included a test case to demonstrate what the perceived issue was.

It's been many years since I've worked with Shiro, but I think this issue was intended to describe that there was (is?) no way to specify a value that ends in a backslash (e.g. specifying the prefix for user principals in the Microsoft format of "DOMAIN\principal").

Here's a partial test case added to IniTest#testSplitKeyValue that fails:

 
{code:java}
        test = "Truth=Beauty\\\\";
        kv = Ini.Section.splitKeyValue(test);
        assertEquals("Truth", kv[0]);
        assertEquals("Beauty\\", kv[1]);
{code}
The additional escaping of backslashes within string literals can be confusing, so here's what it was intended to convey. In the INI file:

 

 
{code:java}
Truth=Beauty\\
{code}
And the expected value:

 

 
{code:java}
Beauty\
{code}
Instead, the actual value is:

 

 
{code:java}
Beauty
{code}
This seems to suggest a different (but related?) issue, which is that Ini#splitKeyValue doesn't understand a literal backslash anywhere in a key-value definition (when encountering a backslash character, it doesn't consider whether the previous character was also a backslash, so it just discards both characters). So this also fails:

 
{code:java}
        test = "Truth=Beau\\\\ty";
        kv = Ini.Section.splitKeyValue(test);
        assertEquals("Truth", kv[0]);
        assertEquals("Beau\\ty", kv[1]);
{code}
Sorry again for the vague description.

 

 

> INI parser does not properly handled backslashes at end of values
> -----------------------------------------------------------------
>
>                 Key: SHIRO-530
>                 URL: https://issues.apache.org/jira/browse/SHIRO-530
>             Project: Shiro
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 1.2.3
>            Reporter: atomicknight
>            Priority: Major
>
> The backslash character is overloaded for use as a continuation delimiter as well as an escape character. However, the parsing logic does not presently handle this character consistently, which prevents the use of odd numbers of backslashes at the end of values. Here is a matrix of examples:
> ||Original value||Parsed value||Notes||
> |{noformat}
> key=value\
> {noformat}|{noformat}
> key=value
> {noformat}|Backslash treated as continuation delimiter|
> |{noformat}
> key=value\\
> {noformat}|{noformat}
> key=value\\
> {noformat}|Backslashes treated as literal characters|
> |{noformat}
> key=value\\\
> {noformat}|{noformat}
> key=value\\
> {noformat}|Final backslash treated as continuation delimiter, other backslashes treated as literal characters|
> |{noformat}
> key=value\\\\
> {noformat}|{noformat}
> key=value\\\\
> {noformat}|Backslashes treated as literal characters|
> There is a comment in Ini.Section#isContinued(String) that states:
> {quote}
> //find the number of backslashes at the end of the line.  If an even number, the
> //backslashes are considered escaped.  If an odd number, the line is considered continued on the next line
> {quote}
> However, there is no unescaping logic in either Ini.Section#toMapProps(String) (which calls #isContinued) or IniSection#splitKeyValue(String).



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