[
https://issues.apache.org/jira/browse/WW-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539492#comment-14539492
]
Josef Vermach edited comment on WW-4437 at 5/12/15 8:30 AM:
------------------------------------------------------------
After upgrade to Struts 2.3.20 we have a lot of messages like
{noformat}2015-04-30 04:12:07 CEST TP-Processor48 WARN CookieInterceptor[PTO
CAB6B12D31FCA5328740F548E0798B83.online2]: Cookie name [mini] with value
[%7B%22....%22%7D] was rejected!{noformat}
I found that problem is that value is not accepted.
It worked correctly with Struts 2.3.16.3. Can we somehow solve it?
was (Author: jvermach):
After upgrade to Struts 2.3.20 we have a lot of messages like
{noformat}2015-04-30 04:12:07 CEST TP-Processor48 WARN CookieInterceptor[PTO
CAB6B12D31FCA5328740F548E0798B83.online2]: Cookie name [minibasketContent] with
value
[%7B%22uuid%22%3A%22911b3a4f-4bc6-4e5b-9d37-1f207786dd47%22%2C%22count%22%3A1%2C%22total%22%3A%2224.95%22%7D]
was rejected!{noformat}
I found that problem is that value is not accepted.
It worked correctly with Struts 2.3.16.3. Can we somehow solve it?
> Bug in CookieInterceptor
> ------------------------
>
> Key: WW-4437
> URL: https://issues.apache.org/jira/browse/WW-4437
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors
> Affects Versions: 2.3.20
> Reporter: Chris Pratt
> Assignee: Lukasz Lenart
> Fix For: 2.3.24
>
>
> Sorry, I don't have an environment set up to create a patch, but I found an
> error in the {{CookieInterceptor.isAccepted()}} method. It currently looks
> like:
> {code:java}
> /**
> * Checks if name of Cookie match {@link #acceptedPattern}
> *
> * @param name of Cookie
> * @return true|false
> */
> protected boolean isAccepted(String name) {
> boolean matches = acceptedPattern.matcher(name).matches();
> if (matches) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Cookie [#0] matches acceptedPattern [#1]", name,
> ACCEPTED_PATTERN);
> }
> } else {
> if (LOG.isTraceEnabled()) {
> LOG.trace("Cookie [#0] doesn't match acceptedPattern [#1]", name,
> ACCEPTED_PATTERN);
> }
> }
> return matches;
> }
> {code}
> But it would be more useful if it actually reported the RegEx being used
> instead of the default. And, it would be more performant if the comparisons
> were reversed. So something more like:
> {code:java}
> /**
> * Checks if name of Cookie match {@link #acceptedPattern}
> *
> * @param name of Cookie
> * @return true|false
> */
> protected boolean isAccepted (String name) {
> boolean matches = acceptedPattern.matcher(name).matches();
> if(LOG.isTraceEnabled()) {
> if(matches) {
> LOG.trace("Cookie [#0] matches acceptedPattern
> [#1]",name,acceptedPattern.pattern());
> } else {
> LOG.trace("Cookie [#0] doesn't match acceptedPattern
> [#1]",name,acceptedPattern.pattern());
> }
> }
> return matches;
> }
> {code}
> In addition, it looks like the default and the override are handled
> differently. The current code compiles the default case-insensitive, but not
> the override pattern. Shouldn't that be consistent?
> {code:java}
> private Pattern acceptedPattern =
> Pattern.compile(ACCEPTED_PATTERN,Pattern.CASE_INSENSITIVE);
> public void setAcceptCookieNames (String pattern) {
> acceptedPattern = Pattern.compile(pattern);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
