Details

    • Type: Bug Bug
    • Status: Contributed Solution
    • Priority: Critical 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.
    • Similar Issues:
      Show 5 results 

      Description

      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

        Activity

        Hide
        Gavin Wan (Inactive) added a comment - - Restricted to

        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.

        Show
        Gavin Wan (Inactive) added a comment - - Restricted to 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.
        Hide
        Christoph Jerolimov added a comment - - Restricted to

        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?

        Show
        Christoph Jerolimov added a comment - - Restricted to 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?
        Hide
        Gavin Wan (Inactive) added a comment - - Restricted to

        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 ?

        Show
        Gavin Wan (Inactive) added a comment - - Restricted to 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 ?
        Hide
        Christoph Jerolimov added a comment -

        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" ?

        Show
        Christoph Jerolimov added a comment - 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" ?
        Hide
        Fuad Efendi added a comment - - Restricted to

        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).

        Show
        Fuad Efendi added a comment - - Restricted to 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).
        Hide
        Fuad Efendi added a comment - - Restricted to

        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...

        Show
        Fuad Efendi added a comment - - Restricted to 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...
        Hide
        Fuad Efendi added a comment -

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

        Show
        Fuad Efendi added a comment - Not a bug; it happens behind Apache HTTPD mod_proxy_ajp only, v. 2.2, "worker".
        Hide
        Fuad Efendi added a comment - - Restricted to

        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?

        Show
        Fuad Efendi added a comment - - Restricted to 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?
        Hide
        Fuad Efendi added a comment - - Restricted to

        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...

        Show
        Fuad Efendi added a comment - - Restricted to 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...

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development

                Structure Helper Panel