You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Richard Vermillion (JIRA)" <ji...@apache.org> on 2010/11/05 20:16:43 UTC

[jira] Created: (WW-3529) In xwork-core, NamedVariablePatternMatcher does not properly escape characters

In xwork-core, NamedVariablePatternMatcher does not properly escape characters
------------------------------------------------------------------------------

                 Key: WW-3529
                 URL: https://issues.apache.org/jira/browse/WW-3529
             Project: Struts 2
          Issue Type: Bug
          Components: Other
    Affects Versions: 2.2.1
            Reporter: Richard Vermillion


The com.opensymphony.xwork2.util.NamedVariablePatternMatcher class has a bug in the compilePattern(String) method.  The purpose of the method is to compile patterns such as "action/{foo}" to a regular expression Pattern and extract the variable names that match each group in the regex.  In the example given and the 2.2.1 code base, the pattern will be compiled as "action/([^/]+)".  However, if the pattern includes characters that have special meaning to Java's regular expression engine, they are currently not being escaped.

For example, the pattern "action.{format}" is being compiled to "action.([^/]+)" which correctly matches "action.html" but also "actionK.html" or any other character because the '.' is not escaped.  The bug really bites when a pattern like "{name}.{format}" is used.  This will be compiled to "([^/]+).([^/]+)" which will match "cars.html" but not the way you expect.  Because of greediness, it will set name = "cars.ht" and format = "l".

I will submit a patch to fix this behavior on the next screen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] [Updated] (WW-3529) In xwork-core, NamedVariablePatternMatcher does not properly escape characters

Posted by "Lukasz Lenart (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WW-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lukasz Lenart updated WW-3529:
------------------------------

    Fix Version/s: 3.x
    
> In xwork-core, NamedVariablePatternMatcher does not properly escape characters
> ------------------------------------------------------------------------------
>
>                 Key: WW-3529
>                 URL: https://issues.apache.org/jira/browse/WW-3529
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 2.2.1
>            Reporter: Richard Vermillion
>             Fix For: 3.x
>
>         Attachments: NamedVariablePatternMatcher.patch
>
>
> The com.opensymphony.xwork2.util.NamedVariablePatternMatcher class has a bug in the compilePattern(String) method.  The purpose of the method is to compile patterns such as "action/{foo}" to a regular expression Pattern and extract the variable names that match each group in the regex.  In the example given and the 2.2.1 code base, the pattern will be compiled as "action/([^/]+)".  However, if the pattern includes characters that have special meaning to Java's regular expression engine, they are currently not being escaped.
> For example, the pattern "action.{format}" is being compiled to "action.([^/]+)" which correctly matches "action.html" but also "actionK.html" or any other character because the '.' is not escaped.  The bug really bites when a pattern like "{name}.{format}" is used.  This will be compiled to "([^/]+).([^/]+)" which will match "cars.html" but not the way you expect.  Because of greediness, it will set name = "cars.ht" and format = "l".
> I will submit a patch to fix this behavior on the next screen.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (WW-3529) In xwork-core, NamedVariablePatternMatcher does not properly escape characters

Posted by "Richard Vermillion (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WW-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Vermillion updated WW-3529:
-----------------------------------

    Attachment: NamedVariablePatternMatcher.patch

Added a patch to NamedVariabelPatternMatcher.java

> In xwork-core, NamedVariablePatternMatcher does not properly escape characters
> ------------------------------------------------------------------------------
>
>                 Key: WW-3529
>                 URL: https://issues.apache.org/jira/browse/WW-3529
>             Project: Struts 2
>          Issue Type: Bug
>          Components: Other
>    Affects Versions: 2.2.1
>            Reporter: Richard Vermillion
>         Attachments: NamedVariablePatternMatcher.patch
>
>
> The com.opensymphony.xwork2.util.NamedVariablePatternMatcher class has a bug in the compilePattern(String) method.  The purpose of the method is to compile patterns such as "action/{foo}" to a regular expression Pattern and extract the variable names that match each group in the regex.  In the example given and the 2.2.1 code base, the pattern will be compiled as "action/([^/]+)".  However, if the pattern includes characters that have special meaning to Java's regular expression engine, they are currently not being escaped.
> For example, the pattern "action.{format}" is being compiled to "action.([^/]+)" which correctly matches "action.html" but also "actionK.html" or any other character because the '.' is not escaped.  The bug really bites when a pattern like "{name}.{format}" is used.  This will be compiled to "([^/]+).([^/]+)" which will match "cars.html" but not the way you expect.  Because of greediness, it will set name = "cars.ht" and format = "l".
> I will submit a patch to fix this behavior on the next screen.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.