You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Josef Vermach (JIRA)" <ji...@apache.org> on 2015/05/12 10:31:01 UTC
[jira] [Comment Edited] (WW-4437) Bug in CookieInterceptor
[ 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)