Bug 803544
| Summary: | ViewExpiredException when using Portlet Bridge over WSRP with WS Security | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Portal Platform 5 | Reporter: | Miroslav Cupák <mcupak> | ||||
| Component: | Portal, PortletBridge | Assignee: | Thomas Heute <theute> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.2.1.ER01 | CC: | epp-bugs, mwringe, theute, tkyjovsk | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 5.2.1.ER03 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
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
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-02-10 03:19:18 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Miroslav Cupák
2012-03-15 00:50:46 UTC
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. |