Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces, browser with cookies disabled
-
Support Case References:
-
Affects:Documentation (User Guide, Ref. Guide, etc.)
Description
Browsers can be configured not to accepted cookies, typically for privacy reasons. By using URL re-writing, it should be possible to support ICEfaces on browsers with cookies disabled.
By making use of HttpSession.getId() the JSESSIONID could be included as an ICEfaces bridge configuration parameter and used in subsequent Ajax requests, thereby associating them with the session.
Note that this approach would only support "cookieless" mode in synchronous (non-push) applications. The ICEfaces bridge requires cookies to be enabled in the browser for any asynchronous (push) applications for intra-viewport communications related to asynchronous connection management. No alternative approaches that do not use cookies have been identified as of yet to replace this functionality.
By making use of HttpSession.getId() the JSESSIONID could be included as an ICEfaces bridge configuration parameter and used in subsequent Ajax requests, thereby associating them with the session.
Note that this approach would only support "cookieless" mode in synchronous (non-push) applications. The ICEfaces bridge requires cookies to be enabled in the browser for any asynchronous (push) applications for intra-viewport communications related to asynchronous connection management. No alternative approaches that do not use cookies have been identified as of yet to replace this functionality.
Activity
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Assignee Priority | P2 |
| Fix Version/s | 1.8.2-RC1 [ 10210 ] |
| Issue Type | Improvement [ 4 ] | New Feature [ 2 ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19201 | Mon Aug 31 08:03:35 MDT 2009 | mircea.toma | |
| Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/bridge/src/connection.async.js
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/DOMResponseWriter.java
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/BridgeExternalContext.java
MODIFY
/icefaces/trunk/icefaces/bridge/src/connection.js
|
| Assignee | Deryk Sinotte [ deryk.sinotte ] | Mircea Toma [ mircea.toma ] |
| Fix Version/s | 1.8.2 [ 10190 ] | |
| Affects | [Documentation (User Guide, Ref. Guide, etc.)] | |
| Assignee Priority | P2 | |
| Assignee | Deryk Sinotte [ deryk.sinotte ] |
| Description |
Browsers can be configured not to accepted cookies, typically for privacy reasons. By using URL re-writing, it should be possible to support ICEfaces on browsers with cookies disabled. By making use of HttpSession.getId() the JSESSIONID could be included as an ICEfaces bridge configuration parameter and used in subsequent Ajax requests, thereby associating them with the session. |
Browsers can be configured not to accepted cookies, typically for privacy reasons. By using URL re-writing, it should be possible to support ICEfaces on browsers with cookies disabled. By making use of HttpSession.getId() the JSESSIONID could be included as an ICEfaces bridge configuration parameter and used in subsequent Ajax requests, thereby associating them with the session. Note that this approach would only support "cookieless" mode in synchronous (non-push) applications. The ICEfaces bridge requires cookies to be enabled in the browser for any asynchronous (push) applications for intra-viewport communications related to asynchronous connection management. No alternative approaches that do not use cookies have been identified as of yet to replace this functionality. |
| Salesforce Case | [50070000008IvKl] |
| Support Case References | https://www.icesoft.ca:4443/supportilla/show_bug.cgi?id=5316 |
I think this would also solve another big problem we have: Our users really want to have multiple sessions going at once in different windows/tabs. If the session was decouple from the cookie, each browser window/tab could track to a different user session.
Btw, we know about the concurrent DOM view thing, but that won't work for us. We can't make all our beans request-scoped, because there is state we have that needs to survive hitting the browser's refresh button. We've implemented our scope, called PageScope, which is akin to conversation scope in Seam. But the objects are really stored in the session scope, so they would all be shared between each of the views.
Show
User Ansel1
added a comment - I think this would also solve another big problem we have: Our users really want to have multiple sessions going at once in different windows/tabs. If the session was decouple from the cookie, each browser window/tab could track to a different user session.
Btw, we know about the concurrent DOM view thing, but that won't work for us. We can't make all our beans request-scoped, because there is state we have that needs to survive hitting the browser's refresh button. We've implemented our scope, called PageScope, which is akin to conversation scope in Seam. But the objects are really stored in the session scope, so they would all be shared between each of the views.
| Field | Original Value | New Value |
|---|---|---|
| Affects Version/s | 1.6 [ 10031 ] | |
| Affects Version/s | 1.7DR#2 [ 10110 ] |
Changed bridge configuration to contain calculated AJAX request paths instead of containing only the webapps context path.
By doing this the server has a chance to also rewrite the calculated AJAX request paths to contain the session ID used for session tracking.
Also, URIs passed to ExternalContext.redirect() directly or indirectly by using navigation rules will be rewritten for session tracking.