[
https://issues.apache.org/jira/browse/SHIRO-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070379#comment-17070379
]
atomicknight commented on SHIRO-530:
------------------------------------
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)
