More on ResourceProxyServlet in WSRP

Monday, June 25, 2007

An earlier blog post I wrote, WSRP and Remote Resources, talked about how to use the ResourceProxyServlet to serve resources such as images and css from the producer to the browser by using the consumer as a proxy. This is often necessary because the producer is behind a firewall and the browser cannot access resources on the producer directly.

One feature of the ResourceProxyServlet is that it also proxies response headers from the producer to the end user's browser. This is a nice feature because resources often have headers associated with them that control caching and expiration. Unfortunately, the set-cookie header can also be copied to the browser and if the consumer and producer share the same cookie name and path this can result in the producer cookie overwriting the consumer cookie causing a loss of session on the consumer.

This issue is well documented in the Federated Portals Guide under the Configuring Session Cookies section. The documentation available here presents two potential solutions to the problem, one involving changing the cookie name or path and the other blocking the proxying of all response headers.

I was recently assisting a client on WLP 10 who was experiencing this issue and neither of the above two options were particularly optimal for their situation. The client had existing infrastructure that relied on the JSESSIONID cookie name that would need to be re-configured if this was changed. The second solution would prevent the client from controlling some headers that they may want to tune in the future.

Fortunately, a new feature has been added in WLP 10 that provides a better solution then either of the two currently documented. In the file wsrp-producer-registry.xml, a new stanza has been added called resource-cookies. This allows developers to configure whether or not producers can set cookies when resources are requested through the ResourceProxyServlet. By default, this is set to block-none which allows the producer to set cookies as needed, by changing this to block-all the set-cookie header is no longer proxied from the producer thereby preventing the session issue in a much cleaner way then the current alternatives.

This feature should be documented on edocs in the near future. I would like to thank Subbu Allamaraju for his detailed explanation of this feature when I stumbled across it.

Posted by Gerald Nunn at 4:01 PM | Categories: WebLogic | | | Permalink