You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Anju Geethabai (JIRA)" <ji...@apache.org> on 2007/05/23 11:38:42 UTC
[jira] Created: (STR-3043) issues with tag
issues with <bean:include> tag
------------------------------
Key: STR-3043
URL: https://issues.apache.org/struts/browse/STR-3043
Project: Struts 1
Issue Type: Bug
Affects Versions: 1.2.7
Environment: Struts 1.2 on WebSphere Application server - version 6
Reporter: Anju Geethabai
The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STR-3043) issues with tag
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41106 ]
Niall Pemberton commented on STR-3043:
--------------------------------------
This looks like a duplicate of STR-2569 which we closed as WONTFIX.
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3043) issues with tag
Posted by "Martin Cooper (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Cooper updated STR-3043:
-------------------------------
Component/s: Taglibs
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Components: Taglibs
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
> Fix For: 1.4.0
>
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3043) issues with tag
Posted by "Paul Benedict (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Benedict updated STR-3043:
-------------------------------
Fix Version/s: (was: 1.4.0)
Future
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Components: Taglibs
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
> Fix For: Future
>
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3043) issues with tag
Posted by "Paul Benedict (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Benedict updated STR-3043:
-------------------------------
Fix Version/s: 1.4.0
It might be worth fixing this anyway. Assigning to 1.4 just in case.
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
> Fix For: 1.4.0
>
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STR-3043) issues with tag
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell updated STR-3043:
-------------------------------
Flags: (was: [Patch])
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STR-3043) issues with tag
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41099 ]
Henri Yandell commented on STR-3043:
------------------------------------
It can't just use the cookie as that might not be being used right?
So the logic would need to be:
x = getRequestedSessionId()
y = getCookie("jsessionid") [loop over getCookies]
if(y.length > x.length) ...
else ....
http://java.sun.com/products/servlet/2.1/api/javax.servlet.http.HttpServletRequest.html#getRequestedSessionId() says:
"Gets the session id specified with this request. This may differ from the actual session id. For example, if the request specified an id for an invalid session, then this will get a new session with a new id."
So vague as to whether the case of 'this method doesn't even return the session id' is allowed within the spec or not. Wonder why Websphere doesn't return its session id from this method.
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STR-3043) issues with tag
Posted by "Henri Yandell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/STR-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41112 ]
Henri Yandell commented on STR-3043:
------------------------------------
Sounds good. Anju, are you able to move to the JSTL c:import tag?
> issues with <bean:include> tag
> ------------------------------
>
> Key: STR-3043
> URL: https://issues.apache.org/struts/browse/STR-3043
> Project: Struts 1
> Issue Type: Bug
> Affects Versions: 1.2.7
> Environment: Struts 1.2 on WebSphere Application server - version 6
> Reporter: Anju Geethabai
>
> The logic for the Apache STRUTs tag bean:include causes a new connection to be opened to request a page to be included in the final response for a JSP. The data used to build the new request includes the session ID from the original request, which is stored in the JSESSIONID cookie for the new request. In theory, this should allow the new request to access session data that may have been created in the original request. The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.
> WebSphere JSESSIONID cookie actually consists of the session ID itself, and the routing information for the request (which is used to ensure the request makes it back to the same servant where the session is actually being stored, also known as the affinity token). So, the JSESSIONID created by STRUTs is actually incorrect for IBM® WebSphere® Application Server v6.0
> In practice, this means that any JSPs or servlets included using bean:include will not have access to any original session data created for the request. Instead the 'offshoot' new request created by this tag will cause new sessions to be created for the new request, and any information stored during processing of the offshoot request will ultimately be lost.
> The STRUTs code uses a call to HttpServletRequest.getRequestedSessionId() to create this JSESSIONID cookie on the new request.The contents of getRequestedSessionId() is not guaranteed to be equal to the contents of the JSESSIONID cookie, So the struts code should just access the current request's JSESSIONID cookie and copy that information to the new cookie
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.