Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-75807

Public Render Parameters submitted in a ResourceRequest via ResourceURL do not contain prepended parameter values and incorrectly cause value changes to be propagated to other portlets on the same portal page

    Details

      Description

      Related Issues

      NOTE: The reproducer portlet attached to this issue will not work correctly until the fix for LPS-75244 is merged first.

      Problem Background

      Portlet 2.0 provides the ability to set a Public Render Parameter (PRP), which is (in theory) present in a URL and whose value is propagated to other portlets on the same portal page. The value propagation should take place just before the RenderRequest is created (due to a RenderURL being requested), or just before an ActionRequest is created (due to an ActionURL being requested). The problem is that Liferay Portal is also propagating the value just before a ResourceRequest is created (due to a ResourceURL being requested). This violates section PLT.13.6 of the JSR 286 (Portlet 2.0) specification titled "Resource URLs" which states:

      ResourceURLs cannot change the current portlet mode, window state or render parameters. Parameters set on a resource URL are not render parameters but parameters for serving this resource and will last only for the current serveResource request.

      In addition, section PLT.11.1.1.4 of the Spec titled "Resource Request Parameters" states:

      If a resource parameter is set that has the same name as a render parameter, the render parameter must be the last entry in the parameter value array.

      So if a PRP has a value of "foo" that was previously set by a RenderURL, then a ResourceURL created in the RenderPhase triggered by the RenderURL should prepend its values. For example, resourceURL.setParameter("myPRP", "bar") would result in ResourceRequest parameter values new String[] {"bar", "foo"}. Currently Liferay would only have a single string value of "bar", replacing the "foo" value rather than prepending it.

      Associated TCK Failures

      Liferay Portal does not fail any tests in the Portlet 2.0 TCK due to this issue. However, in the Portlet 3.0 TCK, it does fail V2URLTests_ResourceURL_ApiRenderResurl_resourceURL4 (in part due to this issue). V2AddlRequestTests_SPEC2_11_Resource_publicRenderParameters7 intermittently fails due to this issue.

      Steps to Reproduce.

      First, deploy the attached com.liferay.issue.lps75808.portlet.war artifact to $LIFERAY_HOME/deploy

      Next, follow the Steps 1-6 in the lps75807-foo portlet:

      Step 1: Click this RenderURL to set myPRP to [1, 2, 3]
      Step 2: Examine the value of myPRP above and ALSO in the lps75807-bar portlet and verify that the value in both places is [1, 2, 3]
      Step 3: Click this resourceURL
      Step 4: Verify that the value above is [a, b, c, 1, 2, 3] and dismiss this browser tab in order to return to the first browser tab
      Step 5: Click this RenderURL in order to refresh the page
      Step 6: Examine the value of myPRP above and ALSO in the lps75807-bar portlet and verify that the value in both places is [1, 2, 3]
      Step 7: Click this to submit a form via ActionURL
      Step 8: Examine the value of myPRP above and verify that the ACTION_PHASE value is [x, y, z, 1, 2, 3] and that the RENDER_PHASE value is [x, y, z]).
      Also examine the lps75807-bar portlet and verify that the value from the RENDER_PHASE is [x, y, z].

      Expected Results

      Steps 2, 4, 6, and 8 contain the correct values.

      Actual Results

      Steps 2 and 6 both show a value of [a, b, c] in the lps75807-bar portlet, indicating that the ResourceURL activated in Step#3 caused the public render parameter to be propagated as a result of the ResourceRequest triggered by the ResourceURL. In addition, Step 4 contains a value of [a, b, c] instead of [a, b, c, 1, 2, 3] indicating that the [a, b, c] was not prepended to [a, b, c, 1, 2, 3].

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                brian.chan Brian Chan
                Reporter:
                neil.griffin Neil Griffin
                Participants of an Issue:
                Recent user:
                Csaba Turcsan
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Days since last comment:
                  1 year, 44 weeks, 6 days ago

                  Packages

                  Version Package
                  7.0.0 DXP FP33
                  7.0.0 DXP FP37
                  7.0.0 DXP SP7
                  7.0.5 CE GA6
                  7.0.X
                  7.1.X
                  Master