Description of problem: Let's say you have 2 instances of EPP, one acting as a consumer, the other one as a producer. You have a portlet based on JBoss Portlet Bridge placed on a portal page on the consumer side. It is being used over WSRP with the consumer configured to use WS Security. Navigating in the portlet might lead to javax.faces.application.ViewExpiredExceptionn being logged on the producer side and the portlet not working as a result. How reproducible: This only happens under specific circumstances, but I was able to reproduce it repeadly using the steps in the next section. Steps to Reproduce: 1. Configure WSRP with WS Security on your EPP. Instructions are available at https://community.jboss.org/wiki/GateInWSRPAndWebServiceSecurity. You should have two server configurations (consumer, producer) after that. 2. Start the producer instance and the consumer instance. 3. Deploy your portlet on the producer. I used Seam Booking Demo since it makes use of WS Security when used over WSRP. 4. Sign into the consumer instance as "root". 5. Configure the consumer to use WSRP v2 and WS Security (check "Enable WS Security" in the WSRP configuration portlet). 6. Import the portlet. 7. Add the remote portlet on a page and access it. The portlet should be displayed. If you're using the booking demo, you can see that WS Security works and the user is logged in. 8. Try to navigate somewhere in the portlet. In case of the booking demo, try to search for something. You will get an exception and the portlet displays its error handling page. Additional info: This problem occurs only when WS Security is enabled. In other words, if you checked "Enable WS Security" on the consumer in the WSRP config portlet (even if the portlets don't need it), you will hit this issue with the bridge. If you disable it, everything will work (unless your portlet needs WS Security obviously).
Created attachment 570137 [details] Exception from the server log of the producer (w/ Portal Booking Demo).
Found sort of a workaround for this problem: 1. Follow the "Steps to Reproduce" section until you hit the error. 2. Go to WSRP config portlet. Disable WS Security and refresh the consumer. 3. Go to the page with your portlet. In case of the booking demo, the search page is not displayed since the user is not logged in. 4. Go back to WSRP config portlet. Enable WS Security and refresh the consumer again. 5. Return to the page with the portlet. Try searching for the hotels. Everything should work now.
Unsuccessful attempts at workaround (i.e. what doesn't make it work): - Following the workaround from the previous comment without step 3. Disabling WSS, refreshing the consumer, enabling WSS and doing another refresh doesn't do the trick. - Starting a new session. - Creating a new registration for the consumer. - Producer restart. - Server restart. - Clearing cache.
Is this a regression?
Not a regression (but it is not reproducible on 5.2.0.GA with the Portal Booking Demo because of GTNWSRP-274).
Assigned to Ken Finnigan since I'm not going anywhere with the PBR code.
Not a blocker.
Have verified it's not an issue with PBR. The problem is that the initial RenderRequest (displaying the hotel search page) is part of one Session, and then typing a character to search for hotels has a different Session Id when it reaches the Bridge. As they are different Sessions, this is why a ViewExpiredException is occuring as the new Session doesn't have the ViewState from the previous one.
Assigning back to Chris as I'm not sure whether it's a PC or WSRP issue
The issue has been fixed in wsrp trunk and 2.1.x branch. The issue was caused with the wss handler being added to the wrong location in the handler chain, which caused the session cookie not to be set at the right point. This caused the session to be lost on each invocation between the producer and consumer when ws-security was enabled.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: The cookie session handler and the ws-security handler were not being set in the right order. Consequence: The session was not being set on each request from the producer and the consumer when ws-security was enabled. This meant that on each request a session was being created and any portlets which relied on sessions would not function properly. Fix: Change the order of the web service handlers so that the session would be properly added on each invocation between the consumer and producer. Result: Sessions now work properly with WSRP when WS-Security is enabled
Chris Laprun <chris.laprun> updated the status of jira GTNWSRP-282 to Resolved
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,7 +1 @@ -Cause: The cookie session handler and the ws-security handler were not being set in the right order. +The cookie session handler was not being set on each request from the producer and the consumer when ws-security was enabled. A session was created on each request, and any portlets that relied on sessions would not function properly. The fix implements changes to the order of the web service handlers that ensure the session is properly added on each invocation between the consumer and producer. Sessions now work properly with WSRP when WS-Security is enabled- -Consequence: The session was not being set on each request from the producer and the consumer when ws-security was enabled. This meant that on each request a session was being created and any portlets which relied on sessions would not function properly. - -Fix: Change the order of the web service handlers so that the session would be properly added on each invocation between the consumer and producer. - -Result: Sessions now work properly with WSRP when WS-Security is enabled
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.