[
https://issues.apache.org/jira/browse/GEODE-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995255#comment-15995255
]
ASF GitHub Bot commented on GEODE-1728:
---------------------------------------
GitHub user upthewaterspout opened a pull request:
https://github.com/apache/geode/pull/489
GEODE-1728: Http session filter should only apply to REQUEST
The docs should not tell users to add apply the session filter to
FORWARD, INCLUDE, and ERROR dispatchers. It should just be the default,
REQUEST.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/upthewaterspout/incubator-geode
feature/GEODE-1728
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/geode/pull/489.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #489
----
commit ce634f4ab194bf378a8890ed1f3069396e8ce72a
Author: Dan Smith <upthewatersp...@apache.org>
Date: 2017-05-03T17:16:41Z
GEODE-1728: Http session filter should not be applied to FORWARDS
The docs should not tell users to add apply the session filter to
FORWARD, INCLUDE, and ERROR dispatchers. It should just be the default,
REQUEST.
----
> SessionCachingFilter can create multiple sessions when requests are forwarded
> -----------------------------------------------------------------------------
>
> Key: GEODE-1728
> URL: https://issues.apache.org/jira/browse/GEODE-1728
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
> Reporter: Dan Smith
> Assignee: Karen Smoler Miller
>
> Our installer adds this configuration to the users web.xml file for the
> session state replication:
> {code}
> <filter-mapping>
> <filter-name>gemfire-session-filter</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>FORWARD</dispatcher>
> <dispatcher>INCLUDE</dispatcher>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>ERROR</dispatcher>
> </filter-mapping>
> {code}
> This means that our filter will be applied to all incoming requests, and it
> will be applied *again* if the request is forwarded to or includes another
> servlet.
> We wrap the HttpServletRequest in our own RequestWrapper class. We have some
> code that tries to prevent wrapping a request multiple times:
> {code}
> /**
> * Early out if this isn't the right kind of request. We might see a
> * RequestWrapper instance during a forward or include request.
> */
> if (request instanceof RequestWrapper ||
> !(request instanceof HttpServletRequest)) {
> LOG.debug("Handling already-wrapped request");
> chain.doFilter(request, response);
> return;
> }
> {code}
> Unfortunately, this check will not work if there are *other* filters in the
> chain that also wrap the HttpServletRequest. That can result in us wrapping
> the forwarded request in a new RequestWrapper that will create another
> session.
> We should not add these <dispatcher/> elements to the web.xml; it should be
> sufficient for our filter to intercept all requests initially. In addition,
> we might want to enhance our check to see if we have already wrapped a
> request to follow the chain of wrapped requests deeper. As long as other
> filters wrap the request in a subclass of HttpServletRequestWrapper we should
> be able to unwrap the request if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
