[
https://issues.apache.org/jira/browse/WW-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543315#comment-14543315
]
Josef Vermach edited comment on WW-4437 at 5/14/15 7:20 AM:
------------------------------------------------------------
Hi,
Thanks it helped. We are now able to run our application.
But the problem with rejected cookie still persists. I think (it seems to me
from the code) it is because that accepted_pattern, which we define in struts
default xml, is in struts 2.3.24 used as well for value (in struts 2.3.16.3 it
was not). We will try to change our pattern. Thanks for helping.
Question: Is it good idea to check value and name with same pattern, or I
understood it wrongly?
was (Author: jvermach):
Hi,
Thanks it helped. We are now able to run our application.
But the problem with rejected cookie still persists. I think it is because that
accepted_pattern, which we define in struts, is in struts 2.3.24 used as well
for value (in struts 2.3.16.3 it was not). We will try to change our pattern.
Thanks for helping.
> 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)
