Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 3.1.0.BETA1
-
Fix Version/s: 3.1.0.BETA2, 3.1, EE-3.0.0.GA_P01
-
Labels:None
-
Environment:Portal ICEpush
Description
The symptom is a SessionExpiredException reported by our custom exception handler.
-
Hide
- multi-view-push-test.zip
- 21 kB
- Deryk Sinotte
-
- multi-view-push/.DS_Store 6 kB
- __MACOSX/multi-view-push/._.DS_Store 0.1 kB
- multi-view-push/build.xml 0.8 kB
- multi-view-push/pom.xml 1 kB
- multi-view-push/src/main/.DS_Store 6 kB
- __MACOSX/multi-view-push/.../._.DS_Store 0.1 kB
- multi-view-push/.../DebugPhaseListener.java 0.8 kB
- multi-view-push/src/.../sample/Simple.java 2 kB
- multi-view-push/src/.../resources/.DS_Store 6 kB
- __MACOSX/multi-view-push/.../._.DS_Store 0.1 kB
- multi-view-push/src/.../webapp/.DS_Store 6 kB
- __MACOSX/multi-view-push/.../._.DS_Store 0.1 kB
- multi-view-push/src/.../simple01.xhtml 0.6 kB
- multi-view-push/src/.../simple02.xhtml 0.6 kB
- multi-view-push/src/.../WEB-INF/.DS_Store 6 kB
- __MACOSX/multi-view-push/.../._.DS_Store 0.1 kB
- multi-view-push/src/.../faces-config.xml 1 kB
- multi-view-push/src/main/.../WEB-INF/web.xml 3 kB
- multi-view-push-portlet/build.xml 1 kB
- __MACOSX/.../._build.xml 0.2 kB
- multi-view-push-portlet/pom.xml 7 kB
- multi-view-push-portlet/.../liferay-display.xml 2 kB
- multi-view-push-portlet/.../liferay-plugin-package.properties 2 kB
- multi-view-push-portlet/.../liferay-portlet.xml 3 kB
- multi-view-push-portlet/src/.../portlet.xml 3 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Thanks for looking into this Deryk.
Using the Chrome console and two simple test portlets, you can see the issue happening. After initial load of the portal page but before any interaction, we query for all the ViewStates. Since there are two portlets and 3 forms per portlet (1 that is from the portlet markup and two hidden ones that ICEfaces inserts), it returns 6 values, 3 for each portlet:
document.getElementsByName('javax.faces.ViewState');
[
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-3978125222353783743:1573083955214999241" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-3978125222353783743:1573083955214999241" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="-3978125222353783743:1573083955214999241" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
]
After clicking the "Update with Push" button, the console logs which updates are being applied:
...
[window] applied updates >>
..
update["javax.faces.ViewState"]: -3978125222353783743:1573083955214999241.... location3:1230
[window] applied updates >>
...
update["javax.faces.ViewState"]: -3978125222353783743:1573083955214999241.... location3:1230
[window] applied updates >>
...
update["javax.faces.ViewState"]: 7928353047340332639:-1008142066134303525.... location3:1230
Querying again for the ViewState values, you can see that all of the forms now have the ViewState of the second portlet:
document.getElementsByName('javax.faces.ViewState');
[
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off">
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off" style>
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off" style>
,
<input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="7928353047340332639:-1008142066134303525" autocomplete="off" style>
If I read the logging correctly, it may be applying 3 sets up updates (one client-initiated and 2-push initiated) each time the button in the test case is clicked (triggering a render):
The first update looks like a push response where both portlets are getting updated with the first portlet's ViewState:
[window] applied updates >>
update["_jpfcpncuivr_A4157_j_id1:porFrm1:_t6"]: <span id="_jpfcpncuivr_A4157_j_id1:porFr....
update["_jpfcpncuivr_A4157_j_id1:porFrm1:_t10"]: <span id="_jpfcpncuivr_A4157_j_id1:porFr....
update["dynamic-code-compat"]: <span id="dynamic-code-compat"></span>....
update["javax.faces.ViewState"]: -1592934675537635146:-618886728610481250.... location3:1230
The next update appears to be a response to the button click and only updates the first portlet with it's proper ViewState:
[window] applied updates >>
update["_jpfcpncuivr_A4157_j_id1:porFrm1:_t6"]: <span id="_jpfcpncuivr_A4157_j_id1:porFr....
update["javax.faces.ViewState"]: -1592934675537635146:-618886728610481250.... location3:1230
Then the third response is another push response that updates both portlets with the second portlet's ViewState, leaving is in an undesirable state on the client:
[window] applied updates >>
update["_jpfcpncuivr_A3977_j_id1:porFrm2:_t6"]: <span id="_jpfcpncuivr_A3977_j_id1:porFr....
update["_jpfcpncuivr_A3977_j_id1:porFrm2:_t10"]: <span id="_jpfcpncuivr_A3977_j_id1:porFr....
update["dynamic-code-compat"]: <span id="dynamic-code-compat"></span>....
update["javax.faces.ViewState"]: -3747725226717534306:-454402066662664180....
Since you can successfully use the push-enabled button on the second portlet multiple times, this would further indicate that the problem is ViewState updates are not being confined to the portlet/view to which they belong.
The issue is in our core application.js file and is related to changes in ICE-7188. The section of code in question is:
//MyFaces uses a linked list of view state keys to track the changes in the view state – the participating
//forms need to have their view state key updated so that the next submit will work with the latest saved state
//ICE-7188
var formViewID;
namespace.onBeforeSubmit(function(source)
{ formViewID = formOf(source)['ice.view'].value; console.warn("BEFORE SUBMIT: form id = " + formViewID); });
namespace.onAfterUpdate(function(updates) {
ifViewStateUpdated(updates, function(viewState) {
//update only the forms that have the same viewID with the one used by the submitting form
each(document.getElementsByTagName('form'), function(form) {
var viewIDElement = form['ice.view'];
var viewStateElement = form['javax.faces.ViewState'];
if (viewStateElement && viewIDElement && viewIDElement.value == formViewID)
});
});
});
What happens in the above two sections is that, before a submit is done, the view id of the form that initiated the request is stored. Then after the updates are applied, we make an attempt to ensure the all the forms in the view that originally made the submission are updated with the new ViewState values. However, in the case there are multiple views (portlets) on the pages and Push is used, there are additional requests made by Push but the form id is never updated. So the last ViewState update that arrives due to a Push response will potentially update all the forms on the page because the original form id is still referenced.
The responsible change was r26345 done for ICE-7465.
case 'begin':
//trigger notification only when submit is user-initiated
if (!source || source.id != retrieveUpdateFormID(viewIDOf(source)))
break;
In that case, a test was put in to prevent onBeforeSubmit listeners from being called if the request was triggered by something other than the client request (ie push). This was to prevent the status indicators from firing unless the request came from a purposeful, client interaction. Unfortunately, bluntly turning off all onBeforeSubmit callbacks causes the problem we see here.
Checked in some changes to prevent the updated ViewState being applied to forms outside the relevant portlet that initiated the request or push updates.
Thanks Deryk!
This fix should be applied to the maintenance branch for EE 3.0.0.GA_P01.
Changes applied to the maintenance branch:
Sending compat/core/src/main/javascript/status.js
Sending core/src/main/javascript/application.js
Sending core/src/main/javascript/blockui.js
Committed revision 29265.
Attaching simple test case that uses push across portlets on the same page.
Here are my notes on the issue to date:
1) The issue seems constrained to a problem with Push. I can run and interact with two separate portlets without seeing the issue. The exception only occurs after one or two Push renders are triggered.
2) The SessionExpiredException is slightly misleading. We add that exception handling to attempt to catch cases where a ViewExpiredException is thrown in a situation when the session has expired. In this case, it's not a session expiry but truly a ViewExpiredException.
3) I've narrowed it down to the fact to an update that comes back and updates the javax.faces.ViewState so that the returned value is applied to all views on the page (not just the portlet it actually belongs to. I've also constructed a test case that illustrates the ViewState "contamination" that occurs. In other words, when interacting with the first portlet and triggering a push, the updates for the 2nd portlet also include a ViewState value that gets applied back to the 1st portlet. Any subsequent interaction with that first portlet will throw a ViewExpiredException but that ViewState value doesn't exist for that view.