dev@javaserverfaces.java.net

RE: Util.componentIsDisabledOrReadonly(UIComponent component) Question

From: Jesse Alexander \(KSFD 121\) <"Jesse>
Date: Wed, 31 Jan 2007 23:14:29 +0100

Why should I allow JS to change a value that I have marked as readonly?
I consider this to be a security hole...
 
but then... JS is not really a good thing to use
 
regards
Alexander

________________________________

From: Jason Lee [mailto:lee_at_iecokc.com]
Sent: Wednesday, January 31, 2007 10:56 PM
To: dev_at_javaserverfaces.dev.java.net
Cc: esnunes_at_dev.java.net
Subject: Util.componentIsDisabledOrReadonly(UIComponent component)
Question


A user reported on IRC that he's getting an error/message about not
having a setter for a textarea that is marked readonly. We were able to
track down the issue to the method
Util.componentIsDisabledOrReadonly(UIComponent component). The code
currently looks like this:
 
    public static boolean componentIsDisabledOrReadonly(UIComponent
component) {
 
        boolean disabledOrReadonly =
 
Boolean.valueOf(String.valueOf(component.getAttributes().get("disabled")
));
        if (disabledOrReadonly) {
            return true;
        }
        disabledOrReadonly =
 
Boolean.valueOf(String.valueOf(component.getAttributes().get("disabled")
));
        return disabledOrReadonly;
 
    }
 
The most obvious problem is that the disabled attribute is checked
twice, and the readonly attribute is never checked. Changing the second
check to look at "readonly" is trivial. In fact, unless my from-the-hip
coding is off, one could say
 
    return
Boolean.valueOf(String.valueOf(component.getAttributes().get("disabled")
)) ||
Boolean.valueOf(String.valueOf(component.getAttributes().get("readonly")
));
 
A question arose during the discussion, though: Why is this done at
all. I told the questioner that performance was likely the reason, but,
as we discussed further, I began to see that this behavior may actually
break an app. Just becase a field is marked readonly or disabled
doesn't mean the value has not changed, as JavaScript can easily change
that value. That raise the question, though, of whether or not readonly
or disable form elements are submitted back to server on form
submission. I've not tested to see that (the thought just occurred to
me as I was typing :).
 
So, do we retain this behavior with the fix noted above, or should this
behavior be removed?
 
-----
Jason Lee, SCJP
Programmer/Analyst
http://www.iec-okc.com <http://www.iec-okc.com/>