You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/08/09 07:51:30 UTC

DO NOT REPLY [Bug 35895] - Attributes with false in TLD prevent EL evaluation

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35895>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35895





------- Additional Comments From craig.mcclanahan@sun.com  2005-08-09 07:51 -------
(In reply to comment #0)
> In different tld files, different attributes are configured with
> <rtexprvalue>false</rtexprvalue>
> which prevents using EL in a JSP 2.0 Servlet Container.
> 
> This is the case for instance in
> - html: tag "javascript" attribute "dynamicJavascript"
> - tiles: tag "insert" attribute "attribute"
> - bean: tag "struts" attribute "id"
> 
> I can't recognize any logic explaining why some attributes accept runtime
> expressions and other don't. I think that all attributes should accept runtime
> expression to allow EL use.

I don't recall the particular provenance of these particular decisions, but the
last one in particular reminds me of why we made a similar restriction in JSF
1.0 (you can't use an expression for the "id" property of a component).  It
turns out that allowing expressions for this case would allow a class of cross
site scripting attacks that would make the application vulnerable.  I can look
up the details if need be, but they were compelling enough for the JSF expert
group to set rtexprvalue to false on this attribute (as well as a couple of
other sensitive ones).


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org