Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.1, EE-2.0.0.GA
-
Fix Version/s: 2.1-Beta, 3.0, EE-2.0.0.GA_P01
-
Labels:None
-
Environment:ICEfaces 2 WebSphere Portal 7
Description
Initially logging into a WebSphere 7 portal page results in this kind of URL:
http://192.168.55.111:10039/wps/myportal/!ut/p/b1/04_Sj9CPykssy0xPLMnMz0vM0Q90LSrKLwpOLS4G8kMyc1PzS0tAiqLM4p3dHT1MzH0MDCxMLQwNPB09Qs3Ngl2MDFzN9cP1o_AqCTSBKjDAARwN9P2w2VyQ4eVR7qioCAABx-t_/dl4/d5/L3dJdyEvUUd3SndBQSEvNEprRS9aNl8wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBBMA!!/
In the resulting page markup, the ICEpush configuration info looks like this:
<span id="A1176:v2fvcng6_icepush">
<script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/hY7BjoIwFEW_xS94r1KgLhslClQHBgHphhBSlYkK0xYS_fpxJrM13t1NTu49IKEi_oL4jLgMDiBvzdSdGtv1t-by26VXo5c4iVi6NF5_uhjmdLeKaEQQCZQg_5Dlmm-oLxCZywiGfJP7XraaY0r_AXwRjm8WuAO7QOteZ8qYp9W-u6p-tM_nSvov1dgcSq1MP-pWQdo27VkJNalL0pwUZHBAWmdfbIhFMBoMrNgH1JLOxqKlk8iHD1IttrEZtlleF_e7Lh9OkRc85TZ6fNN0NoOrjIKjqsIf4eBGPw!!/";
</script>
</span>
Using Firebug, you can see that the initial request to get the bridge.js file is:
http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/
The original request to get icepush.js is:
http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3LDoIwFES_xS-4t1AoLBtAECqiiEo3pGkaxYioIN_vI26d3ZmczICE2nfQZT6zLDiAvKqpPaqx7a_q8mHpNugWdiECh2bxxsFFRfMwpSlBJLAH-VWCmCeUCUTP8QgueFIxtwwt5PZPwD_hCHnSd-a9VEv298qzYP8wQ_98aANrrfTJCDOZS6GOBko4IG3Ks3fLRPQcMBrFNqIjacdMaDqJ6rYidbP8dFlgr3A53Mngk918HfHY5PNQz6CTaWJ3AX8BX6pOrQ!!/
The ICEpush config on the page is set to use the same URL as it did for getting the ICEfaces bridge:
<span id="A1176:v2fvcngc_icepush">
<script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/";
</script>
</span>
On Liferay, the ICEpush configuration results in something like this:
<span id="A9944:v9iqym2_icepush">
<script type="text/javascript">/*<![CDATA[*/ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/web/guest/chat1?_chatice2portlet_WAR_chatportlet_INSTANCE_nh4N_javax.faces.resource={{command}}&p_p_cacheability=cacheLevelPage&p_p_col_count=1&p_p_col_id=column-1&p_p_id=chatice2portlet_WAR_chatportlet_INSTANCE_nh4N&p_p_lifecycle=2&p_p_mode=view&p_p_state=normal";/*]]>*/
</script>
</span>
It seems likely that this is all related to WebSphere Portal 7's own support for back button history in that a bunch of state is encoded into URLs. Not sure it's playing nice with what we want to do. For example, we replace the {{command}} marker dynamically in the URL but once it's been encoded by WebSphere, it's no longer there to be replaced.
From WebSphere's own documentation:
"Considerations for administrators about Back button behavior
The Back button behavior of the portal is internally achieved by coding the combination of all states into the address of the view, that is into its URL. Thus each different combination of navigational states results in a different URL. This has the following additional advantages:
Users can set separate bookmarks for different states of the same page.
You can have pages cached by configuring specific requirements. For more details about how to do this, refer to Caching.
However, make no assumptions about the syntax or structure of portal URLs. For example, you cannot create valid URLs by simple concatenation. This will automatically be true if only the public API is used to create URLs. The latest version of the IBM Portlet API Javadoc is always available from the WebSphere Portal Product Documentation page."
http://192.168.55.111:10039/wps/myportal/!ut/p/b1/04_Sj9CPykssy0xPLMnMz0vM0Q90LSrKLwpOLS4G8kMyc1PzS0tAiqLM4p3dHT1MzH0MDCxMLQwNPB09Qs3Ngl2MDFzN9cP1o_AqCTSBKjDAARwN9P2w2VyQ4eVR7qioCAABx-t_/dl4/d5/L3dJdyEvUUd3SndBQSEvNEprRS9aNl8wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBBMA!!/
In the resulting page markup, the ICEpush configuration info looks like this:
<span id="A1176:v2fvcng6_icepush">
<script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/hY7BjoIwFEW_xS94r1KgLhslClQHBgHphhBSlYkK0xYS_fpxJrM13t1NTu49IKEi_oL4jLgMDiBvzdSdGtv1t-by26VXo5c4iVi6NF5_uhjmdLeKaEQQCZQg_5Dlmm-oLxCZywiGfJP7XraaY0r_AXwRjm8WuAO7QOteZ8qYp9W-u6p-tM_nSvov1dgcSq1MP-pWQdo27VkJNalL0pwUZHBAWmdfbIhFMBoMrNgH1JLOxqKlk8iHD1IttrEZtlleF_e7Lh9OkRc85TZ6fNN0NoOrjIKjqsIf4eBGPw!!/";
</script>
</span>
Using Firebug, you can see that the initial request to get the bridge.js file is:
http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/
The original request to get icepush.js is:
http://192.168.55.111:10039/wps/myportal/Home/chat/!ut/p/b1/dY3LDoIwFES_xS-4t1AoLBtAECqiiEo3pGkaxYioIN_vI26d3ZmczICE2nfQZT6zLDiAvKqpPaqx7a_q8mHpNugWdiECh2bxxsFFRfMwpSlBJLAH-VWCmCeUCUTP8QgueFIxtwwt5PZPwD_hCHnSd-a9VEv298qzYP8wQ_98aANrrfTJCDOZS6GOBko4IG3Ks3fLRPQcMBrFNqIjacdMaDqJ6rYidbP8dFlgr3A53Mngk918HfHY5PNQz6CTaWJ3AX8BX6pOrQ!!/
The ICEpush config on the page is set to use the same URL as it did for getting the ICEfaces bridge:
<span id="A1176:v2fvcngc_icepush">
<script type="text/javascript">ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/wps/myportal/Home/chat/!ut/p/b1/dY3NjoIwFEafxSe4t1AoLBskIlQHhilIN6QhjTIRYaCS6NPPT2br2X3JyXdAQRN66LOQOQ6cQN302p-17cebvv5u5bfo524uIo9mu3cP95IetylNCSKBGtSfEu14QplADLyA4J4nkvnl1kHu_gv4Ao5wTMbB_Dw1ir1MBQ7Us1nG-9wZKDrdXYwwq7nm-myghBPStvwMpkzE9wVjKz5iaklvM9HRVcjpjTThIVumQynb6vGY66dbyYoX3KbPL1psNjCoNHGHiH8DL6JcbQ!!/";
</script>
</span>
On Liferay, the ICEpush configuration results in something like this:
<span id="A9944:v9iqym2_icepush">
<script type="text/javascript">/*<![CDATA[*/ice.push.configuration.contextPath="/";ice.push.configuration.uriPattern="/web/guest/chat1?_chatice2portlet_WAR_chatportlet_INSTANCE_nh4N_javax.faces.resource={{command}}&p_p_cacheability=cacheLevelPage&p_p_col_count=1&p_p_col_id=column-1&p_p_id=chatice2portlet_WAR_chatportlet_INSTANCE_nh4N&p_p_lifecycle=2&p_p_mode=view&p_p_state=normal";/*]]>*/
</script>
</span>
It seems likely that this is all related to WebSphere Portal 7's own support for back button history in that a bunch of state is encoded into URLs. Not sure it's playing nice with what we want to do. For example, we replace the {{command}} marker dynamically in the URL but once it's been encoded by WebSphere, it's no longer there to be replaced.
From WebSphere's own documentation:
"Considerations for administrators about Back button behavior
The Back button behavior of the portal is internally achieved by coding the combination of all states into the address of the view, that is into its URL. Thus each different combination of navigational states results in a different URL. This has the following additional advantages:
Users can set separate bookmarks for different states of the same page.
You can have pages cached by configuring specific requirements. For more details about how to do this, refer to Caching.
However, make no assumptions about the syntax or structure of portal URLs. For example, you cannot create valid URLs by simple concatenation. This will automatically be true if only the public API is used to create URLs. The latest version of the IBM Portlet API Javadoc is always available from the WebSphere Portal Product Documentation page."
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Deryk Sinotte
created issue -
Deryk Sinotte
made changes -
Field | Original Value | New Value |
---|---|---|
Salesforce Case | [] | |
Fix Version/s | EE-2.0.0.GA_P01 [ 10271 ] | |
Assignee | Mircea Toma [ mircea.toma ] |
Ken Fyten
made changes -
Salesforce Case | [] | |
Fix Version/s | 2.1 [ 10241 ] |
Mircea Toma
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Mircea Toma
made changes -
Resolution | Fixed [ 1 ] | |
Status | Resolved [ 5 ] | Reopened [ 4 ] |
Mircea Toma
made changes -
Status | Reopened [ 4 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Fix Version/s | 2.1-Beta [ 10291 ] | |
Fix Version/s | 2.1 [ 10241 ] |
Ken Fyten
made changes -
Fix Version/s | 3.0 [ 10241 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |