My guess is no, that will no longer work. This is because Struts
automatically surrounds whatever you put in that attribute with '%{}'.
Therefore, your input field:
<s:textfield name="%{fieldnames.phoneFieldName}" />
Will actually be evaluated as if it was:
<s:textfield name="%{%{fieldnames.phoneFieldName}%}" />
The relevant lines of code are in UIBean.java starting at 727 or so:
if (value != null) {
addParameter("nameValue", findValue(value,
valueClazz));
} else if (name != null) {
String expr = name;
if (altSyntax()) {
expr = "%{" + expr + "}";
}
addParameter("nameValue", findValue(expr,
valueClazz));
}
As you can see, if the value isn't specified, we wrap the name in '%{}' and
evaluate it.
As to how we could support your use case, I'm not sure. Perhaps you could
use a JSP EL expression to resolve the field name as I believe JSP EL is
evaluated before Struts gets a hold of it.
Don
On 7/25/07, Fowler, Perryn <[EMAIL PROTECTED]> wrote:
Hi guys,
I have a question about the implementation of this security fix - I'm
worried that it may break something that I rely on.
SHORT VERSION
Does this fix prevent recursive evaluation when generating the
HTML 'name' attribute as well as the 'value' attribute?
LONG VERSION
As I understand it the problem is that when you write something like
<s:textfield name="phone" />
This generates an HTML tag where the value attribute is evaluated as
something like
value="%{phone}"
and if %{phone} evaluates to %{1+1} ( for example) you get
value="%{%{1+1}}"
which recursively evaluates to
value="2"
so the fix is to turn of recursive OGNL evaluation so we will get
value="%{1+1}"
So far so good.
My problem is that in a number of apps I have relied on the ability to
do something like
<s:textfield name="%{fieldnames.phoneFieldName}" />
and I provide a fieldnames object on the stack with the
getPhoneFieldName() returning "phone"
Which generates a HTML tag where the *name* attribute ( rather than the
value attribute) is evaluated as
name="%{fieldnames.phoneFieldName}"
which evaluates to
name="phone"
in the HTML.
This allows me to maintain all my field names ( and hence the mapping of
these fields onto my domain) in one place, rather than having the same
literal strings scattered through the application.
So, my question (finally) is, will this still work with the security
fix?
I will get the fix and try it our myself as soon as I can get to it, but
I thought I would ask here in the meantime.
Cheers
Perryn
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ted Husted
Sent: Wednesday, 25 July 2007 1:47 AM
To: Struts Users Mailing List
Subject: [ANN] Struts 2.0.9 General Availability Release with Important
Security Fix
Apache Struts 2.0.9 is now available from
<http://struts.apache.org/download.cgi#struts209?update=200707231930>.
This release includes an important security fix regarding a remote
code exploit. For more information about the exploit, visit our
security bulletins page at
<http://struts.apache.org/2.x/docs/s2-001.html>.
* ALL DEVELOPERS ARE STRONGLY ADVISED TO UPDATE TO STRUTS 2.0.9 OR
XWORK 2.0.4 IMMEDIATELY!
For other changes included in Struts 2.0.9, see the release notes
<http://struts.apache.org/2.0.9/docs/release-notes-209.html>.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
"This e-mail and any attachments to it (the "Communication") is, unless
otherwise stated, confidential, may contain copyright material and is for
the use only of the intended recipient. If you receive the Communication in
error, please notify the sender immediately by return e-mail, delete the
Communication and the return e-mail, and do not read, copy, retransmit or
otherwise deal with it. Any views expressed in the Communication are those
of the individual sender only, unless expressly stated to be those of
Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any
of its related entities including ANZ National Bank Limited (together
"ANZ"). ANZ does not accept liability in connection with the integrity of or
errors in the Communication, computer virus, data corruption, interference
or delay arising from or in respect of the Communication."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
