[jira] Created: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
--
Key: WW-2107
URL: https://issues.apache.org/struts/browse/WW-2107
Project: Struts 2
Issue Type: Bug
Components: Views
Affects Versions: 2.0.9
Reporter: Don Brown
Priority: Blocker
Fix For: 2.0.10
It is possible for a user to submit malicious OGNL that could be executed in a
page that uses JSP EL expressions in Struts tag attributes. FreeMarker pages
that use FreeMarker expressions in Struts tag attributes are also affected.
For example, say you had this JSP page fragement:
And a user submitted, via a validation error or request url query parameter,
the value:
bar=%{1+1}
What happens is the JSP processor gets the page first and processes the JSP EL
expression resulting in:
Then, the Struts 2 tag receives the 'value' attribute value and processes the
OGNL expression, resulting in this:
The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
Struts tag attributes because you could be unwittingly allowing arbitrary code
execution.
The proposed solution is to turn off, via the TLD, JSP EL expressions in all
Struts tag attributes. This will mostly likely break many Struts 2
applications, but the severity of the issue needs to be taken into account.
This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WW-2108) Make being able to remember selected tab using a cookie
Make being able to remember selected tab using a cookie --- Key: WW-2108 URL: https://issues.apache.org/struts/browse/WW-2108 Project: Struts 2 Issue Type: New Feature Components: Views Affects Versions: 2.0.9 Reporter: Rene Gielen Fix For: 2.0.10, 2.1.0 Right now, the only chance to influence the selected tab of a tabbed panel tag is to provide the selectedTab attribute manually. It would be good to have the option to save the state (aka the last selected tab) so that the user finds this activated again when he comes back to the same view. There is also a DOJO ticket for this, but it seems like there is nothing happening: http://trac.dojotoolkit.org/ticket/1865 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Don Brown updated WW-2107:
--
Description:
It is possible for a user to submit malicious OGNL that could be executed in a
page that uses JSP EL expressions in Struts tag attributes. FreeMarker pages
that use FreeMarker expressions in Struts tag attributes are also affected.
Velocity pages are not affected.
For example, say you had this JSP page fragement:
And a user submitted, via a validation error or request url query parameter,
the value:
bar=%{1+1}
What happens is the JSP processor gets the page first and processes the JSP EL
expression resulting in:
Then, the Struts 2 tag receives the 'value' attribute value and processes the
OGNL expression, resulting in this:
The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
Struts tag attributes because you could be unwittingly allowing arbitrary code
execution.
The proposed solution is to turn off, via the TLD, JSP EL expressions in all
Struts tag attributes. This will mostly likely break many Struts 2
applications, but the severity of the issue needs to be taken into account.
This solution doesn't unfortunately resolve the FreeMarker issue.
was:
It is possible for a user to submit malicious OGNL that could be executed in a
page that uses JSP EL expressions in Struts tag attributes. FreeMarker pages
that use FreeMarker expressions in Struts tag attributes are also affected.
For example, say you had this JSP page fragement:
And a user submitted, via a validation error or request url query parameter,
the value:
bar=%{1+1}
What happens is the JSP processor gets the page first and processes the JSP EL
expression resulting in:
Then, the Struts 2 tag receives the 'value' attribute value and processes the
OGNL expression, resulting in this:
The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
Struts tag attributes because you could be unwittingly allowing arbitrary code
execution.
The proposed solution is to turn off, via the TLD, JSP EL expressions in all
Struts tag attributes. This will mostly likely break many Struts 2
applications, but the severity of the issue needs to be taken into account.
This solution doesn't unfortunately resolve the FreeMarker issue.
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> --
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.9
>Reporter: Don Brown
>Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
>
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
>
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
>
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WW-2108) Make being able to remember selected tab using a cookie
[ https://issues.apache.org/struts/browse/WW-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene Gielen reassigned WW-2108: --- Assignee: Rene Gielen > Make being able to remember selected tab using a cookie > --- > > Key: WW-2108 > URL: https://issues.apache.org/struts/browse/WW-2108 > Project: Struts 2 > Issue Type: New Feature > Components: Views >Affects Versions: 2.0.9 >Reporter: Rene Gielen >Assignee: Rene Gielen > Fix For: 2.0.10, 2.1.0 > > > Right now, the only chance to influence the selected tab of a tabbed panel > tag is to provide the selectedTab attribute manually. It would be good to > have the option to save the state (aka the last selected tab) so that the > user finds this activated again when he comes back to the same view. > There is also a DOJO ticket for this, but it seems like there is nothing > happening: > http://trac.dojotoolkit.org/ticket/1865 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41812
]
Don Brown commented on WW-2107:
---
See also http://forums.opensymphony.com/thread.jspa?messageID=176037
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> --
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.9
>Reporter: Don Brown
>Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
>
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
>
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
>
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41820
]
Musachy Barroso commented on WW-2107:
-
I know I've said this before, but I think we are better off blocking any
parameter with a value that looks like %{...}
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> --
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.9
>Reporter: Don Brown
>Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
>
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
>
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
>
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (WW-1948) s:url tag does not provide forceAddSchemeHostAndPort parameter
[ https://issues.apache.org/struts/browse/WW-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on WW-1948 started by James Holmes. > s:url tag does not provide forceAddSchemeHostAndPort parameter > -- > > Key: WW-1948 > URL: https://issues.apache.org/struts/browse/WW-1948 > Project: Struts 2 > Issue Type: Improvement > Components: Views >Reporter: Sami Dalouche >Assignee: James Holmes > Fix For: 2.1.0 > > > URLHelper#buildUrl provides a parameter called forceAddSchemeHostAndPort, > that is not settable from s:url tags (according to > http://struts.apache.org/2.x/docs/url.html). > ./core/src/main/java/org/apache/struts2/components/URL.java uses : > result = UrlHelper.buildUrl(_value, req, res, parameters, scheme, > includeContext, encode); > where it could use the following prototype : > UrlHelper#buildUrl(String action, HttpServletRequest request, > HttpServletResponse response, Map params, String scheme, boolean > includeContext, boolean encodeResult, boolean forceAddSchemeHostAndPort) > Regards, > Sami Dalouche -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WW-1948) s:url tag does not provide forceAddSchemeHostAndPort parameter
[ https://issues.apache.org/struts/browse/WW-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Holmes reassigned WW-1948: Assignee: James Holmes (was: Rainer Hermanns) > s:url tag does not provide forceAddSchemeHostAndPort parameter > -- > > Key: WW-1948 > URL: https://issues.apache.org/struts/browse/WW-1948 > Project: Struts 2 > Issue Type: Improvement > Components: Views >Reporter: Sami Dalouche >Assignee: James Holmes > Fix For: 2.1.0 > > > URLHelper#buildUrl provides a parameter called forceAddSchemeHostAndPort, > that is not settable from s:url tags (according to > http://struts.apache.org/2.x/docs/url.html). > ./core/src/main/java/org/apache/struts2/components/URL.java uses : > result = UrlHelper.buildUrl(_value, req, res, parameters, scheme, > includeContext, encode); > where it could use the following prototype : > UrlHelper#buildUrl(String action, HttpServletRequest request, > HttpServletResponse response, Map params, String scheme, boolean > includeContext, boolean encodeResult, boolean forceAddSchemeHostAndPort) > Regards, > Sami Dalouche -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-1948) s:url tag does not provide forceAddSchemeHostAndPort parameter
[ https://issues.apache.org/struts/browse/WW-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Holmes resolved WW-1948. -- Resolution: Fixed Fix Version/s: 2.0.10 Fixed on the 2_0_X branch in SVN revision 565422. Fixed on the trunk (Struts 2.1) in SVN revision 565429. > s:url tag does not provide forceAddSchemeHostAndPort parameter > -- > > Key: WW-1948 > URL: https://issues.apache.org/struts/browse/WW-1948 > Project: Struts 2 > Issue Type: Improvement > Components: Views >Reporter: Sami Dalouche >Assignee: James Holmes > Fix For: 2.0.10, 2.1.0 > > > URLHelper#buildUrl provides a parameter called forceAddSchemeHostAndPort, > that is not settable from s:url tags (according to > http://struts.apache.org/2.x/docs/url.html). > ./core/src/main/java/org/apache/struts2/components/URL.java uses : > result = UrlHelper.buildUrl(_value, req, res, parameters, scheme, > includeContext, encode); > where it could use the following prototype : > UrlHelper#buildUrl(String action, HttpServletRequest request, > HttpServletResponse response, Map params, String scheme, boolean > includeContext, boolean encodeResult, boolean forceAddSchemeHostAndPort) > Regards, > Sami Dalouche -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WW-1950) UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort turned on (TestCase included)
[
https://issues.apache.org/struts/browse/WW-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Holmes reassigned WW-1950:
Assignee: James Holmes (was: Rainer Hermanns)
> UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort
> turned on (TestCase included)
> ---
>
> Key: WW-1950
> URL: https://issues.apache.org/struts/browse/WW-1950
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8
>Reporter: Sami Dalouche
>Assignee: James Holmes
> Fix For: 2.1.0
>
>
> If you add this test to UrlHelperTest, you will find out that it fails..
> public void testForceAddSchemeHostAndPortWithNonStandardPort() throws
> Exception {
> String expectedUrl =
> "http://localhost:9090/contextPath/path1/path2/myAction.action";;
> Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);
> mockHttpServletRequest.expectAndReturn("getScheme", "http");
> mockHttpServletRequest.expectAndReturn("getServerName", "localhost");
> mockHttpServletRequest.expectAndReturn("getContextPath",
> "/contextPath");
> mockHttpServletRequest.expectAndReturn("getServerPort", 9090);
> Mock mockHttpServletResponse = new Mock(HttpServletResponse.class);
> mockHttpServletResponse.expectAndReturn("encodeURL", expectedUrl,
> expectedUrl);
> String result = UrlHelper.buildUrl("/path1/path2/myAction.action",
> (HttpServletRequest) mockHttpServletRequest.proxy(),
> (HttpServletResponse)mockHttpServletResponse.proxy(), null, "http", true,
> true, true);
> assertEquals(expectedUrl, result);
> mockHttpServletRequest.verify();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (WW-1950) UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort turned on (TestCase included)
[
https://issues.apache.org/struts/browse/WW-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on WW-1950 started by James Holmes.
> UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort
> turned on (TestCase included)
> ---
>
> Key: WW-1950
> URL: https://issues.apache.org/struts/browse/WW-1950
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8
>Reporter: Sami Dalouche
>Assignee: James Holmes
> Fix For: 2.1.0
>
>
> If you add this test to UrlHelperTest, you will find out that it fails..
> public void testForceAddSchemeHostAndPortWithNonStandardPort() throws
> Exception {
> String expectedUrl =
> "http://localhost:9090/contextPath/path1/path2/myAction.action";;
> Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);
> mockHttpServletRequest.expectAndReturn("getScheme", "http");
> mockHttpServletRequest.expectAndReturn("getServerName", "localhost");
> mockHttpServletRequest.expectAndReturn("getContextPath",
> "/contextPath");
> mockHttpServletRequest.expectAndReturn("getServerPort", 9090);
> Mock mockHttpServletResponse = new Mock(HttpServletResponse.class);
> mockHttpServletResponse.expectAndReturn("encodeURL", expectedUrl,
> expectedUrl);
> String result = UrlHelper.buildUrl("/path1/path2/myAction.action",
> (HttpServletRequest) mockHttpServletRequest.proxy(),
> (HttpServletResponse)mockHttpServletResponse.proxy(), null, "http", true,
> true, true);
> assertEquals(expectedUrl, result);
> mockHttpServletRequest.verify();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41822
]
Dale Newfield commented on WW-2107:
---
I'm just a struts user, and not a developer/committer, but I agree with Musachy.
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> --
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.9
>Reporter: Don Brown
>Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
>
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
>
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
>
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WW-2034) Add #action to the context pointing to the last executed action
[ https://issues.apache.org/struts/browse/WW-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Musachy Barroso resolved WW-2034. - Resolution: Fixed Fixed on xwork rv 1581 > Add #action to the context pointing to the last executed action > --- > > Key: WW-2034 > URL: https://issues.apache.org/struts/browse/WW-2034 > Project: Struts 2 > Issue Type: New Feature >Reporter: Musachy Barroso >Assignee: Musachy Barroso >Priority: Minor > Fix For: 2.1.0 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-1950) UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort turned on (TestCase included)
[
https://issues.apache.org/struts/browse/WW-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41824
]
James Holmes commented on WW-1950:
--
The reason why this test fails is because Struts 2 does not currently use the
port from the current request to build new URLs. Instead, Struts 2 uses the two
configurable ports ("struts.url.http.port" and "struts.url.https.port").
The only scenario where the port from the request should be used is in when not
switching between schemes. I have fixed that scenario and added the attached
test case. The test case passes with the fix for using the request port when
not switching schemes.
> UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort
> turned on (TestCase included)
> ---
>
> Key: WW-1950
> URL: https://issues.apache.org/struts/browse/WW-1950
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8
>Reporter: Sami Dalouche
>Assignee: James Holmes
> Fix For: 2.1.0
>
>
> If you add this test to UrlHelperTest, you will find out that it fails..
> public void testForceAddSchemeHostAndPortWithNonStandardPort() throws
> Exception {
> String expectedUrl =
> "http://localhost:9090/contextPath/path1/path2/myAction.action";;
> Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);
> mockHttpServletRequest.expectAndReturn("getScheme", "http");
> mockHttpServletRequest.expectAndReturn("getServerName", "localhost");
> mockHttpServletRequest.expectAndReturn("getContextPath",
> "/contextPath");
> mockHttpServletRequest.expectAndReturn("getServerPort", 9090);
> Mock mockHttpServletResponse = new Mock(HttpServletResponse.class);
> mockHttpServletResponse.expectAndReturn("encodeURL", expectedUrl,
> expectedUrl);
> String result = UrlHelper.buildUrl("/path1/path2/myAction.action",
> (HttpServletRequest) mockHttpServletRequest.proxy(),
> (HttpServletResponse)mockHttpServletResponse.proxy(), null, "http", true,
> true, true);
> assertEquals(expectedUrl, result);
> mockHttpServletRequest.verify();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2107) Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
[
https://issues.apache.org/struts/browse/WW-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41825
]
Don Brown commented on WW-2107:
---
I thought about that as well, but it wouldn't help. For one thing, we would
have to block the string '%{' anywhere in the submitted data, which is very
intrusive, but the kicker is it wouldn't block other attacks. For example, any
attribute that evaluations to a non-string value is automatically evaluated as
OGNL with no '%{}' delimiter necessary. Therefore, blocking '%{}' would help
some cases, but still leave you open for attack in others.
> Arbitrary user-submitted OGNL possible when using JSP EL or FreeMarker
> --
>
> Key: WW-2107
> URL: https://issues.apache.org/struts/browse/WW-2107
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.9
>Reporter: Don Brown
>Priority: Blocker
> Fix For: 2.0.10
>
>
> It is possible for a user to submit malicious OGNL that could be executed in
> a page that uses JSP EL expressions in Struts tag attributes. FreeMarker
> pages that use FreeMarker expressions in Struts tag attributes are also
> affected. Velocity pages are not affected.
> For example, say you had this JSP page fragement:
>
> And a user submitted, via a validation error or request url query parameter,
> the value:
> bar=%{1+1}
> What happens is the JSP processor gets the page first and processes the JSP
> EL expression resulting in:
>
> Then, the Struts 2 tag receives the 'value' attribute value and processes the
> OGNL expression, resulting in this:
>
> The workaround is to ensure you don't use JSP EL or FreeMarker expressions in
> Struts tag attributes because you could be unwittingly allowing arbitrary
> code execution.
> The proposed solution is to turn off, via the TLD, JSP EL expressions in all
> Struts tag attributes. This will mostly likely break many Struts 2
> applications, but the severity of the issue needs to be taken into account.
> This solution doesn't unfortunately resolve the FreeMarker issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2058) Client side validation in xhtml template and clearErrorMessages not working in firefox with hidden fields
[
https://issues.apache.org/struts/browse/WW-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41826
]
Florent Ramière commented on WW-2058:
-
This solution works fine on 2.0.0.6 and Internet explorer 6.0.2
> Client side validation in xhtml template and clearErrorMessages not working
> in firefox with hidden fields
> -
>
> Key: WW-2058
> URL: https://issues.apache.org/struts/browse/WW-2058
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8, 2.0.9
> Environment: Firefox
>Reporter: Max Pimm
>Priority: Minor
>
> The method clearErrorMessages in the xhtml client side validation template
> (template/xhtml/validation.js) fails in firefox. This results in the error
> messages being duplicated each time the form is submitted.
> The problem arises from the first three lines of code in the function:
> var table = form.childNodes[1];
> if( typeof table == "undefined" ) {
> table = form.childNodes[0];
> }
> This presumes that the first (or second) node of the form element is the
> field table. However in firefox hidden fields within a form are moved in the
> DOM to the top of its children. Thus wherever you put the hidden elements in
> the form they appear in the DOM at the top. The same problem does not occur
> in internet explorer or if no hidden fields are present. I have not tried
> other browsers.
> I have replaced these three lines with the patch:
> // get field table
> var table;
> for (var i = 0; i < form.childNodes.length; i++){
> if (form.childNodes[i].tagName != null &&
> form.childNodes[i].tagName.toLowerCase() == "table"){
> table = form.childNodes[i];
> break;
> }
> }
> if (table == null){
> return;
> }
> This solves the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2103) Invalid Javascript generated for StringLength validator
[
https://issues.apache.org/struts/browse/WW-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Ramière updated WW-2103:
Attachment: form-close-validate.ftl.patch
I confirm the bug, this error was scattered across the validation.
Freemarker ouputs number in the default local by default, in order to have
javascript compliant number we need to request the string value using the
?string built-in method.
Note that I fixed also a bug in the stringlength method where the validator was
not triggered when the field value is empty
> Invalid Javascript generated for StringLength validator
>
>
> Key: WW-2103
> URL: https://issues.apache.org/struts/browse/WW-2103
> Project: Struts 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: NetBeans IDE 5.5.1 (Bundled Tomcat 5.5.17), Java 1.6
>Reporter: Jeremy Mikola
>Priority: Minor
> Attachments: form-close-validate.ftl.patch
>
>
> I am attempting to use the StringLength validator for an action's "save"
> alias, to ensure that a text-field input is between 3 and 1024 characters
> long (the minLength and maxLength params, respectively). When testing the
> validation, I noticed that strings of any length were being rejected by the
> client-side Javascript validation (I am using the xhtml theme). Looking at
> the generated Javascript code in the page source, it appears the problem is
> that my maxLength parameter is being printed with locale formatting (as it is
> in when substituted into my error message), rather than as a raw number:
> if(value.length > 0 && (
> (3 > -1 && value.length < 3) ||
> (1,024 > -1 && value.length > 1,024)
> )) {
> addError(field, error);
> errors = true;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2058) Client side validation in xhtml template and clearErrorMessages not working in firefox with hidden fields
[
https://issues.apache.org/struts/browse/WW-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Ramière updated WW-2058:
Attachment: validation.js.patch
Added the patch version
> Client side validation in xhtml template and clearErrorMessages not working
> in firefox with hidden fields
> -
>
> Key: WW-2058
> URL: https://issues.apache.org/struts/browse/WW-2058
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8, 2.0.9
> Environment: Firefox
>Reporter: Max Pimm
>Priority: Minor
> Attachments: validation.js.patch
>
>
> The method clearErrorMessages in the xhtml client side validation template
> (template/xhtml/validation.js) fails in firefox. This results in the error
> messages being duplicated each time the form is submitted.
> The problem arises from the first three lines of code in the function:
> var table = form.childNodes[1];
> if( typeof table == "undefined" ) {
> table = form.childNodes[0];
> }
> This presumes that the first (or second) node of the form element is the
> field table. However in firefox hidden fields within a form are moved in the
> DOM to the top of its children. Thus wherever you put the hidden elements in
> the form they appear in the DOM at the top. The same problem does not occur
> in internet explorer or if no hidden fields are present. I have not tried
> other browsers.
> I have replaced these three lines with the patch:
> // get field table
> var table;
> for (var i = 0; i < form.childNodes.length; i++){
> if (form.childNodes[i].tagName != null &&
> form.childNodes[i].tagName.toLowerCase() == "table"){
> table = form.childNodes[i];
> break;
> }
> }
> if (table == null){
> return;
> }
> This solves the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2058) Client side validation in xhtml template and clearErrorMessages not working in firefox with hidden fields
[
https://issues.apache.org/struts/browse/WW-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Ramière updated WW-2058:
Attachment: validation.js.patch
Please disregard the first patch
> Client side validation in xhtml template and clearErrorMessages not working
> in firefox with hidden fields
> -
>
> Key: WW-2058
> URL: https://issues.apache.org/struts/browse/WW-2058
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8, 2.0.9
> Environment: Firefox
>Reporter: Max Pimm
>Priority: Minor
> Attachments: validation.js.patch, validation.js.patch
>
>
> The method clearErrorMessages in the xhtml client side validation template
> (template/xhtml/validation.js) fails in firefox. This results in the error
> messages being duplicated each time the form is submitted.
> The problem arises from the first three lines of code in the function:
> var table = form.childNodes[1];
> if( typeof table == "undefined" ) {
> table = form.childNodes[0];
> }
> This presumes that the first (or second) node of the form element is the
> field table. However in firefox hidden fields within a form are moved in the
> DOM to the top of its children. Thus wherever you put the hidden elements in
> the form they appear in the DOM at the top. The same problem does not occur
> in internet explorer or if no hidden fields are present. I have not tried
> other browsers.
> I have replaced these three lines with the patch:
> // get field table
> var table;
> for (var i = 0; i < form.childNodes.length; i++){
> if (form.childNodes[i].tagName != null &&
> form.childNodes[i].tagName.toLowerCase() == "table"){
> table = form.childNodes[i];
> break;
> }
> }
> if (table == null){
> return;
> }
> This solves the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-2103) Invalid Javascript generated for StringLength validator
[
https://issues.apache.org/struts/browse/WW-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florent Ramière updated WW-2103:
Attachment: struts2-form-close-validate.ftl.patch
I created a patch using my own svn repository,
struts2-form-close-validate.ftl.patch is the patch against the apache svn.
Please disregard form-close-validate.ftl.patch
> Invalid Javascript generated for StringLength validator
>
>
> Key: WW-2103
> URL: https://issues.apache.org/struts/browse/WW-2103
> Project: Struts 2
> Issue Type: Bug
>Affects Versions: 2.0.9
> Environment: NetBeans IDE 5.5.1 (Bundled Tomcat 5.5.17), Java 1.6
>Reporter: Jeremy Mikola
>Priority: Minor
> Attachments: form-close-validate.ftl.patch,
> struts2-form-close-validate.ftl.patch
>
>
> I am attempting to use the StringLength validator for an action's "save"
> alias, to ensure that a text-field input is between 3 and 1024 characters
> long (the minLength and maxLength params, respectively). When testing the
> validation, I noticed that strings of any length were being rejected by the
> client-side Javascript validation (I am using the xhtml theme). Looking at
> the generated Javascript code in the page source, it appears the problem is
> that my maxLength parameter is being printed with locale formatting (as it is
> in when substituted into my error message), rather than as a raw number:
> if(value.length > 0 && (
> (3 > -1 && value.length < 3) ||
> (1,024 > -1 && value.length > 1,024)
> )) {
> addError(field, error);
> errors = true;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-1977) Struts throws stack trace instead of 404 when an action doesn't exist
[ https://issues.apache.org/struts/browse/WW-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41831 ] Matt Raible commented on WW-1977: - I'm experiencing this on a brand new Struts application that doesn't use AppFuse. Here's my exception: There is no Action mapped for namespace /struts and action name red. - [unknown location] com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:186) org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:41) org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:494) org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419) I'm using Struts 2.0.8. > Struts throws stack trace instead of 404 when an action doesn't exist > - > > Key: WW-1977 > URL: https://issues.apache.org/struts/browse/WW-1977 > Project: Struts 2 > Issue Type: Bug > Components: Actions >Affects Versions: 2.0.6 >Reporter: Matt Raible > Fix For: 2.1.0 > > > If I request an action that doesn't exist, Struts displays a "Struts Problem > Report" page with a stack trace like the following: > here is no Action mapped for namespace / and action name blabla. - [unknown > location] > at > com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:186) > at > org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActio > In my struts.xml: > > > > > value="ApplicationResources,errors"/> > > > > Strangely enough, in another application I was able to change struts.devMode > from true to false to fix this problem. However, since it's already false in > this application, I'm not sure how to fix it. > To reproduce, go to: http://demo.appfuse.org/appfuse-struts/blabla.html and > login with user/user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-1977) Struts throws stack trace instead of 404 when an action doesn't exist
[ https://issues.apache.org/struts/browse/WW-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41832 ] Matt Raible commented on WW-1977: - Some more information: This happens on Tomcat 5.0.25, Tomcat 5.0.28 and Tomcat 6.0.13. It also happens on Jetty 6.1.5. It does *not* happen when using the maven-jetty-plugin (version jetty-6.1.5rc0). On Jetty 6.1.5 standalone, it appears to have information for both the 404 and a 500 - as represented by the error message that's presented: HTTP ERROR: 404 There is no Action mapped for namespace / and action name usersda2. RequestURI=/light/usersda2.html Caused by: There is no Action mapped for namespace / and action name usersda2. - [unknown location] at com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:186) at org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsActionProxyFactory.java:41) at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:494) at org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:419) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.apache.struts2.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:99) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrideFilter.java:125) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.appfuse.web.MessageFilter.doFilter(MessageFilter.java:32) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) Powered by Jetty:// > Struts throws stack trace instead of 404 when an action doesn't exist > - > > Key: WW-1977 > URL: https://issues.apache.org/struts/browse/WW-1977 > Project: Struts 2 > Issue Type: Bug > Components: Actions >Affects Versions: 2.0.6 >Reporter: Matt Raible > Fix For: 2.1.0 > > > If I request an action that doesn't exist, Struts displays a "Struts Problem > Report" page with a stack trace like the following: > here is no Action mapped for namespace / and action name blabla. - [unknown > location] > at > com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:186) > at > org.apache.struts2.impl.StrutsActionProxyFactory.createActionProxy(StrutsAc
[jira] Resolved: (WW-1950) UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort turned on (TestCase included)
[
https://issues.apache.org/struts/browse/WW-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Holmes resolved WW-1950.
--
Resolution: Fixed
Fix Version/s: 2.0.10
Fixed on the 2_0_X branch in SVN revision 565492.
Fixed on the trunk (Struts 2.1) in SVN revision 565609.
Thanks for the heads up and the test case!
> UrlHelper.buildUrl does not output port even if forceAddSchemeHostAndPort
> turned on (TestCase included)
> ---
>
> Key: WW-1950
> URL: https://issues.apache.org/struts/browse/WW-1950
> Project: Struts 2
> Issue Type: Bug
> Components: Views
>Affects Versions: 2.0.8
>Reporter: Sami Dalouche
>Assignee: James Holmes
> Fix For: 2.0.10, 2.1.0
>
>
> If you add this test to UrlHelperTest, you will find out that it fails..
> public void testForceAddSchemeHostAndPortWithNonStandardPort() throws
> Exception {
> String expectedUrl =
> "http://localhost:9090/contextPath/path1/path2/myAction.action";;
> Mock mockHttpServletRequest = new Mock(HttpServletRequest.class);
> mockHttpServletRequest.expectAndReturn("getScheme", "http");
> mockHttpServletRequest.expectAndReturn("getServerName", "localhost");
> mockHttpServletRequest.expectAndReturn("getContextPath",
> "/contextPath");
> mockHttpServletRequest.expectAndReturn("getServerPort", 9090);
> Mock mockHttpServletResponse = new Mock(HttpServletResponse.class);
> mockHttpServletResponse.expectAndReturn("encodeURL", expectedUrl,
> expectedUrl);
> String result = UrlHelper.buildUrl("/path1/path2/myAction.action",
> (HttpServletRequest) mockHttpServletRequest.proxy(),
> (HttpServletResponse)mockHttpServletResponse.proxy(), null, "http", true,
> true, true);
> assertEquals(expectedUrl, result);
> mockHttpServletRequest.verify();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WW-1960) action tag violates ParameterAware contract
[
https://issues.apache.org/struts/browse/WW-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Holmes reassigned WW-1960:
Assignee: (was: James Holmes)
> action tag violates ParameterAware contract
> ---
>
> Key: WW-1960
> URL: https://issues.apache.org/struts/browse/WW-1960
> Project: Struts 2
> Issue Type: Bug
> Components: Actions
>Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9
> Environment: linux,jdk1.5,tomcat5.5
>Reporter: David Mansfield
>Priority: Minor
> Fix For: 2.0.10
>
>
> the javadoc for ParameterAware states that the values of the map are all
> java.lang.String[], in other words it is a Map. Indeed,
> when hitting an action via a 'genuine' http request, this is true. However,
> when hitting the action via the action tag, the values in the map are String,
> not String[]. The bug appears to be possibly line 177 in ActionComponent:
> 176:if (parameters != null) {
> 177:newParams.putAll(parameters);
> 178:}
> The parameters of the component are Map and therefore cannot
> be combined directly into the ActionContext.getParameters map.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-1960) action tag violates ParameterAware contract
[
https://issues.apache.org/struts/browse/WW-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Holmes updated WW-1960:
-
Affects Version/s: 2.0.7
2.0.8
2.0.9
Fix Version/s: (was: Future)
2.0.10
> action tag violates ParameterAware contract
> ---
>
> Key: WW-1960
> URL: https://issues.apache.org/struts/browse/WW-1960
> Project: Struts 2
> Issue Type: Bug
> Components: Actions
>Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9
> Environment: linux,jdk1.5,tomcat5.5
>Reporter: David Mansfield
>Priority: Minor
> Fix For: 2.0.10
>
>
> the javadoc for ParameterAware states that the values of the map are all
> java.lang.String[], in other words it is a Map. Indeed,
> when hitting an action via a 'genuine' http request, this is true. However,
> when hitting the action via the action tag, the values in the map are String,
> not String[]. The bug appears to be possibly line 177 in ActionComponent:
> 176:if (parameters != null) {
> 177:newParams.putAll(parameters);
> 178:}
> The parameters of the component are Map and therefore cannot
> be combined directly into the ActionContext.getParameters map.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (WW-1831) Common use case for stranded messages in MessageStoreInterceptor
[ https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on WW-1831 started by James Holmes. > Common use case for stranded messages in MessageStoreInterceptor > - > > Key: WW-1831 > URL: https://issues.apache.org/struts/browse/WW-1831 > Project: Struts 2 > Issue Type: Improvement > Components: Interceptors >Affects Versions: 2.0.6 >Reporter: Jasper Rosenberg >Assignee: James Holmes > Fix For: Future > > > I have what I think would be a pretty common use case for the > MessageStoreInterceptor where, under some circumstances, messages could be > left in the session, taking up memory unncessarily. > The sample use case is that when someone submits an email change, on success > I want to redirect them back to their home action, passing any messages (i.e. > "Your email has been successfully changed") along for display. I used to do > this with action chaining which worked but was sub-optimal since the user > would end up back at their home page with an url like "updateEmail.action" > rather than "home.action". > MessageStoreInterceptor seems like the right solution for this case as now I > can have the updateEmail store the message, redirect to the home page, and > then have home page retrieve it: > class="com.mycompany.action.HomeAction"> > home.ftl > > RETRIEVE > > > > class="com.mycompany.action.ChangeEmailAction" method="updateEmail"> > > home > > editEmail.ftl > > STORE > > > > The problem is the case when the result of updateEmail is "input" rather than > "success". In this case, I just redisplay the change email form, but any > validation errors will have been stored in the session. If the user then > navigates away or closes the browser, these messages will be stranded in the > session. > I think there is a pretty simple fix for this: > In MessageStoreInterceptor.before(), simply move the lines: > session.remove(actionErrorsSessionKey); > session.remove(actionMessagesSessionKey); > session.remove(fieldErrorsSessionKey); > out of the nested ifs so that they are always the last operations in the > method. > This will handle any case other than a redirect/chain to an action that > doesn't have the interceptor at all (which can't be helped). > Another option to this is to explictly support an additional parameter for > the Interceptor like "clearStoredMessages" which defaults to false, but if > true always calls the session.remove()s at the end of the before(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-1831) Common use case for stranded messages in MessageStoreInterceptor
[ https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41834 ] James Holmes commented on WW-1831: -- I also ran into this same issue. I fixed the problem by not having my main action always be in RETRIEVE operation mode. Instead I passed the operation mode to the main action. I have an example of this below using your original configuration home.ftl home RETRIEVE editEmail.ftl STORE Notice that the operation mode of RETRIEVE is passed as parameter on the redirect-action result. I still believe this should be fixed though and I will work on that. > Common use case for stranded messages in MessageStoreInterceptor > - > > Key: WW-1831 > URL: https://issues.apache.org/struts/browse/WW-1831 > Project: Struts 2 > Issue Type: Improvement > Components: Interceptors >Affects Versions: 2.0.6 >Reporter: Jasper Rosenberg >Assignee: James Holmes > Fix For: Future > > > I have what I think would be a pretty common use case for the > MessageStoreInterceptor where, under some circumstances, messages could be > left in the session, taking up memory unncessarily. > The sample use case is that when someone submits an email change, on success > I want to redirect them back to their home action, passing any messages (i.e. > "Your email has been successfully changed") along for display. I used to do > this with action chaining which worked but was sub-optimal since the user > would end up back at their home page with an url like "updateEmail.action" > rather than "home.action". > MessageStoreInterceptor seems like the right solution for this case as now I > can have the updateEmail store the message, redirect to the home page, and > then have home page retrieve it: > class="com.mycompany.action.HomeAction"> > home.ftl > > RETRIEVE > > > > class="com.mycompany.action.ChangeEmailAction" method="updateEmail"> > > home > > editEmail.ftl > > STORE > > > > The problem is the case when the result of updateEmail is "input" rather than > "success". In this case, I just redisplay the change email form, but any > validation errors will have been stored in the session. If the user then > navigates away or closes the browser, these messages will be stranded in the > session. > I think there is a pretty simple fix for this: > In MessageStoreInterceptor.before(), simply move the lines: > session.remove(actionErrorsSessionKey); > session.remove(actionMessagesSessionKey); > session.remove(fieldErrorsSessionKey); > out of the nested ifs so that they are always the last operations in the > method. > This will handle any case other than a redirect/chain to an action that > doesn't have the interceptor at all (which can't be helped). > Another option to this is to explictly support an additional parameter for > the Interceptor like "clearStoredMessages" which defaults to false, but if > true always calls the session.remove()s at the end of the before(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WW-1831) Common use case for stranded messages in MessageStoreInterceptor
[ https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Holmes updated WW-1831: - Affects Version/s: 2.0.7 2.0.8 2.0.9 > Common use case for stranded messages in MessageStoreInterceptor > - > > Key: WW-1831 > URL: https://issues.apache.org/struts/browse/WW-1831 > Project: Struts 2 > Issue Type: Improvement > Components: Interceptors >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 >Reporter: Jasper Rosenberg >Assignee: James Holmes > Fix For: Future > > > I have what I think would be a pretty common use case for the > MessageStoreInterceptor where, under some circumstances, messages could be > left in the session, taking up memory unncessarily. > The sample use case is that when someone submits an email change, on success > I want to redirect them back to their home action, passing any messages (i.e. > "Your email has been successfully changed") along for display. I used to do > this with action chaining which worked but was sub-optimal since the user > would end up back at their home page with an url like "updateEmail.action" > rather than "home.action". > MessageStoreInterceptor seems like the right solution for this case as now I > can have the updateEmail store the message, redirect to the home page, and > then have home page retrieve it: > class="com.mycompany.action.HomeAction"> > home.ftl > > RETRIEVE > > > > class="com.mycompany.action.ChangeEmailAction" method="updateEmail"> > > home > > editEmail.ftl > > STORE > > > > The problem is the case when the result of updateEmail is "input" rather than > "success". In this case, I just redisplay the change email form, but any > validation errors will have been stored in the session. If the user then > navigates away or closes the browser, these messages will be stranded in the > session. > I think there is a pretty simple fix for this: > In MessageStoreInterceptor.before(), simply move the lines: > session.remove(actionErrorsSessionKey); > session.remove(actionMessagesSessionKey); > session.remove(fieldErrorsSessionKey); > out of the nested ifs so that they are always the last operations in the > method. > This will handle any case other than a redirect/chain to an action that > doesn't have the interceptor at all (which can't be helped). > Another option to this is to explictly support an additional parameter for > the Interceptor like "clearStoredMessages" which defaults to false, but if > true always calls the session.remove()s at the end of the before(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work stopped: (WW-1831) Common use case for stranded messages in MessageStoreInterceptor
[ https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on WW-1831 stopped by James Holmes. > Common use case for stranded messages in MessageStoreInterceptor > - > > Key: WW-1831 > URL: https://issues.apache.org/struts/browse/WW-1831 > Project: Struts 2 > Issue Type: Improvement > Components: Interceptors >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 >Reporter: Jasper Rosenberg >Assignee: James Holmes > Fix For: Future > > > I have what I think would be a pretty common use case for the > MessageStoreInterceptor where, under some circumstances, messages could be > left in the session, taking up memory unncessarily. > The sample use case is that when someone submits an email change, on success > I want to redirect them back to their home action, passing any messages (i.e. > "Your email has been successfully changed") along for display. I used to do > this with action chaining which worked but was sub-optimal since the user > would end up back at their home page with an url like "updateEmail.action" > rather than "home.action". > MessageStoreInterceptor seems like the right solution for this case as now I > can have the updateEmail store the message, redirect to the home page, and > then have home page retrieve it: > class="com.mycompany.action.HomeAction"> > home.ftl > > RETRIEVE > > > > class="com.mycompany.action.ChangeEmailAction" method="updateEmail"> > > home > > editEmail.ftl > > STORE > > > > The problem is the case when the result of updateEmail is "input" rather than > "success". In this case, I just redisplay the change email form, but any > validation errors will have been stored in the session. If the user then > navigates away or closes the browser, these messages will be stranded in the > session. > I think there is a pretty simple fix for this: > In MessageStoreInterceptor.before(), simply move the lines: > session.remove(actionErrorsSessionKey); > session.remove(actionMessagesSessionKey); > session.remove(fieldErrorsSessionKey); > out of the nested ifs so that they are always the last operations in the > method. > This will handle any case other than a redirect/chain to an action that > doesn't have the interceptor at all (which can't be helped). > Another option to this is to explictly support an additional parameter for > the Interceptor like "clearStoredMessages" which defaults to false, but if > true always calls the session.remove()s at the end of the before(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WW-1831) Common use case for stranded messages in MessageStoreInterceptor
[ https://issues.apache.org/struts/browse/WW-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41834 ] jholmes edited comment on WW-1831 at 8/13/07 8:15 PM: --- I also ran into this same issue. I fixed the problem by not having my main action always be in RETRIEVE operation mode. Instead I passed the operation mode to the main action. I have an example of this below using your original configuration home.ftl home RETRIEVE editEmail.ftl STORE Notice that the operation mode of RETRIEVE is passed as parameter on the redirect-action result. was (Author: jholmes): I also ran into this same issue. I fixed the problem by not having my main action always be in RETRIEVE operation mode. Instead I passed the operation mode to the main action. I have an example of this below using your original configuration home.ftl home RETRIEVE editEmail.ftl STORE Notice that the operation mode of RETRIEVE is passed as parameter on the redirect-action result. I still believe this should be fixed though and I will work on that. > Common use case for stranded messages in MessageStoreInterceptor > - > > Key: WW-1831 > URL: https://issues.apache.org/struts/browse/WW-1831 > Project: Struts 2 > Issue Type: Improvement > Components: Interceptors >Affects Versions: 2.0.6, 2.0.7, 2.0.8, 2.0.9 >Reporter: Jasper Rosenberg >Assignee: James Holmes > Fix For: Future > > > I have what I think would be a pretty common use case for the > MessageStoreInterceptor where, under some circumstances, messages could be > left in the session, taking up memory unncessarily. > The sample use case is that when someone submits an email change, on success > I want to redirect them back to their home action, passing any messages (i.e. > "Your email has been successfully changed") along for display. I used to do > this with action chaining which worked but was sub-optimal since the user > would end up back at their home page with an url like "updateEmail.action" > rather than "home.action". > MessageStoreInterceptor seems like the right solution for this case as now I > can have the updateEmail store the message, redirect to the home page, and > then have home page retrieve it: > class="com.mycompany.action.HomeAction"> > home.ftl > > RETRIEVE > > > > class="com.mycompany.action.ChangeEmailAction" method="updateEmail"> > > home > > editEmail.ftl > > STORE > > > > The problem is the case when the result of updateEmail is "input" rather than > "success". In this case, I just redisplay the change email form, but any > validation errors will have been stored in the session. If the user then > navigates away or closes the browser, these messages will be stranded in the > session. > I think there is a pretty simple fix for this: > In MessageStoreInterceptor.before(), simply move the lines: > session.remove(actionErrorsSessionKey); > session.remove(actionMessagesSessionKey); > session.remove(fieldErrorsSessionKey); > out of the nested ifs so that they are always the last operations in the > method. > This will handle any case other than a redirect/chain to an action that > doesn't have the interceptor at all (which can't be helped). > Another option to this is to explictly support an additional parameter for > the Interceptor like "clearStoredMessages" which defaults to false, but if > true always calls the session.remove()s at the end of the before(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2105) Handle redirectAction result type in a portlet
[ https://issues.apache.org/struts/browse/WW-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41835 ] James Holmes commented on WW-2105: -- Ok, I have pasted the configuration for one set of CRUD pages here: /WEB-INF/jsp/admin/ageGroup.jsp STORE /WEB-INF/jsp/admin/ageGroup.jsp ageGroup RETRIEVE /WEB-INF/jsp/admin/ageGroupUpdate.jsp STORE /WEB-INF/jsp/admin/ageGroupUpdate.jsp ageGroup RETRIEVE STORE ageGroup RETRIEVE Let me know if you need anything else to debug this issue. > Handle redirectAction result type in a portlet > -- > > Key: WW-2105 > URL: https://issues.apache.org/struts/browse/WW-2105 > Project: Struts 2 > Issue Type: Bug > Components: Portlet Integration >Reporter: Nils-Helge Garli >Assignee: Nils-Helge Garli > Fix For: 2.1.0 > > > To ease migration of existing web application that use the redirect action > result type, this result type should point to PortletResult when running in a > portlet environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WW-2105) Handle redirectAction result type in a portlet
[ https://issues.apache.org/struts/browse/WW-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_41836 ] Nils-Helge Garli commented on WW-2105: -- Can you show the JSP with the form that both act as input and display the result? > Handle redirectAction result type in a portlet > -- > > Key: WW-2105 > URL: https://issues.apache.org/struts/browse/WW-2105 > Project: Struts 2 > Issue Type: Bug > Components: Portlet Integration >Reporter: Nils-Helge Garli >Assignee: Nils-Helge Garli > Fix For: 2.1.0 > > > To ease migration of existing web application that use the redirect action > result type, this result type should point to PortletResult when running in a > portlet environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
