PortletSession doesn't work in Liferay 5.1 anymore!

• Type: Bug
• Status: Contributed Solution
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: 5.1.0
• Fix Version/s: None
• Component/s: None
• Labels: None
• Environment: Affected: Tested with Sun JDK 1.5 (build 1.5.0_10-b03) and Sun JDK 1.6(build 1.6.0_06-b02) and the Liferay 5.1 bundles Jetty, Tomcat 5.5 and JBoss 5.2. All versions are affected!; Not affected: Liferay 5.0.1 with Tomcat, no more tested.

Hello,

out simple testing code for portlet session was working in Liferay 5.0.1 and not in Liferay 5.1.
On every refresh with got an new empty session with an new session id.

@Override
public void render(RenderRequest request, RenderResponse response) throws PortletException, IOException

{ super.render(request, response); System.out.println(request.getPortletSession().getAttribute("hello") == null ? "not found" : "found"); request.getPortletSession().setAttribute("hello", "world"); System.out.println(request.getPortletSession().getAttribute("hello") == null ? "Hallo nicht da!!!" : "Hallo bereits da!!!"); System.out.println("render sessionId: " + request.getPortletSession().getId()); }

Have you any ideas?

Best regards,
Christoph

[Gavin Wan (Inactive)]

I put the codes into iframe's action to test it.
I can get it.

found
Hallo bereits da!!!
render sessionId: C3F77D96CC6F6679BC426039CFA066B4

trunk(19127) tomcat5.5 windowXP
Please correct me to reproduce the issue.

[Christoph Jerolimov (Inactive)]

What to you mean with the iframe action. Count it be that this portlet has a "special" configuration?

Count you test it with the stable version 5.1 instead of the subversion trunk?

[Gavin Wan (Inactive)]

I was put your code into the Iframe portlet ViewAction's render method.
Then I add the Ifame portlet into a page.
I can get the data when I refresh the page.
Is your testing in EXT environment or plugin environment ?

[Christoph Jerolimov (Inactive)]

I download the liferay 5.1 bundle and deploy my simple portal war file with the file upload option the admin ui. Is this wrong? Have portlets on different deployment mechanism different "features" ?

[Fuad Efendi (Inactive)]

Simply put following into any JSP and do several refreshes of page:
System.out.println("sessionId: " + renderRequest.getPortletSession().getId());

Sometimes printed IDs do not match and it causes NullPointerException in my application, so that I am sure printed ID belongs to my specific request).

You can also use Firefox + LiveHTTP Headers Plugin for troubleshooting (it will show IDs).

It happens in multi-user production; it does not happen in a single-user environment (on my laptop).

It is also possible there is a bug in Apache HTTPD mod_proxy_ajp which I am using as a caching server in front of Liferay.

It happens with Liferay 5.1.2, Tomcat 5.5, HTTPD 2.2 (RedHat).

[Fuad Efendi (Inactive)]

Yes, HTTPD-related.

I just restarted Apache HTTPD and it disappeared; I didn't restart Liferay instance.

Somehow it was sending me wrong cookies... probably multithreading issues; I noticed they recently fixed similar bug with mod_jk, but I am using mod_proxy_ajp, "worker".

BTW, printed PortletSession ID exactly matches to JSESSIONID (visible via LiveHttp plugin for Firefox).

If I am right, it will happen with Liferay 5.2 too... behind same Apache HTTPD...

[Fuad Efendi (Inactive)]

Not a bug; it happens behind Apache HTTPD mod_proxy_ajp only, v. 2.2, "worker".

[Fuad Efendi (Inactive)]

What is status of this issue?

I am unsure that it is HTTPD mod_proxy_ajp bug. This is critical!

It does not happen with HttpSession - why it happens with PortletSession?

[Fuad Efendi (Inactive)]

May be it will help:

1. Fixed in Apache httpd 2.2.12
important: mod_proxy_ajp information disclosure CVE-2009-1191
An information disclosure flaw was found in mod_proxy_ajp in version 2.2.11 only. In certain situations, if a user sent a carefully crafted HTTP request, the server could return a response intended for another user.

2. Fixed in Apache [b]httpd 2.2.6 [/b]
moderate: mod_cache information leak CVE-2007-1862
The recall_headers function in mod_mem_cache in Apache 2.2.4 did not properly copy all levels of header data, which can cause [b][u]Apache to return HTTP headers containing previously used data[/u],[/b] which could be used by remote attackers to obtain potentially sensitive information.

Update Released: 7th September 2007

Affects: 2.2.4

And, of course, our famous vendor [b]RedHat ENTERPRISE[/b](???) still provide us with [b]HTTPD v.2.3.3[/b] (as of October-2009)

We are using mod_mem_cache, I'll try to disable it to see if it helps...