WSRP consumer cookie management and session

[julien1]

It is stated in the WSRP spec that the consumer must return all cookies it receives from the producer, mostly for producer http session tracking.

Today in our producer we use a trick that track session level at wsrp level using the SesssionContext.sessionId and we can force it in tomcat. That avoid us to require the consumer to manage producer cookies.

While this work well with tomcat we have no assurance it will work with other containers (for the future). Furthermore for our consumer, it can limit session maintenance with other producers.

We also know how to get/set headers at the http level using an Handler (or producer or consumer). So we must leverage this in order to

1/ make our consumer manage producer cookies.

2/ make our producer able to set cookies for session tracking instead of using the fake http session during the dispatching to the portlet container.

[julien1]

We must implement on the consumer a generic cookie manager that store the cookies in the consumer portal session and leverage threadlocal + soap handler to read/write headers on the wire.

I believe a lot of code can be borrowed from the initCookie management stuff. And then probably the initCookie stuff can leverage also this manager in order to have a unified management of producer cookies.

[julien1]

On the producer side we must check that the code using the servlet request+response creating an HTTP session will trigger the setting of a cookie on the http response OR if the soap layer will prevent this.

[claprun]

This is mostly how the consumer already works but I'm going to look at the details.

http://jira.jboss.com/jira/browse/JBPORTAL-982

[julien1]

for the actual consumer we scope a cookie for one single portlet or a group of portlet (depending on the producer configuration). In that case we want to send a cookie back to the producer whatever portlet is invoked for that particular producer and without the initCookie initiative.

Section 3.13 of WSRP 2.0 PD says :

Since the transport layer is often used to store various pieces of information (e.g. J2EE load balancing depends on a session cookie and HTTP transport), and these pieces of information often will pertain to a client session with the Consumer rather than the Consumer itself, Consumers that manage transport layer issues, such as cookies, MUST
return them to the Producer only for subsequent invocations within the Markup Interface during the same client
session.

[claprun]

The problem is then how to deal with these cookies. Or, more precisely, how to scope them. They can be accomodated fairly easily already with RequestHeaderClientHandler.

[julien1]

the scope of every cookie must be per producer X user, like a web browser does. this rule does not apply for the cookies got from the initCookie operation of course as those follow specific rules.

For example wsrp4j WS stack does it by default, that's why there is no cookie related code in the wsrp4j. However the docs says :

The WSRP consumer implementation session handling is based on the SOAP stack's session handling. The generated SOAP stubs are doing the cookie handling and are caching the cookies in instance variables. This means that one stub object instance is equivalent to one HTTP session which we map to one WSRP session (initCookie wise). When a WSRP session did time out an InvalidCookie exception is being thrown and a new session must be established.

http://portals.apache.org/wsrp4j/arch/consumer.html