The original intent was definitely that readonly would
block submission, and that's how it worked in JSF 1.1.
I agree with Jesse that there is a potential security
hole if the behavior remains as is. Developers use "readonly"
to mean "this field is not allowed to be edited by this user",
and allowing readonly fields to be updated opens up a hole.
I agree that one might have a UI with a readonly field
that gets updated by JS, but:
- You could use <h:inputHidden> along the side
of the readonly field if necessary
- This is the *basic* HTML renderkit, and should
do the basics safely
-- Adam
Jason Lee said the following on 1/31/07 2:27 PM PT:
> Well, with the current behavior, the RI is forcing a certain behavior on
> the author's application that the author may not want. Maybe there's a
> page that shows some data in a readonly textarea. The user clicks on a
> link and a window pops up with a super fancy editor. The user makes
> some changes and clicks OK, then JavaScript takes the values from Super
> Fancy Editor and updates the values on the original page. While that
> may seem a bit contrived, I wouldn't be too surprised to see an app that
> behaves that way, which is a reasonable expectation, I think...
>
> -----
> Jason Lee, SCJP
> Programmer/Analyst
> http://www.iec-okc.com <http://www.iec-okc.com/>
>
>
> ------------------------------------------------------------------------
> *From:* Jesse Alexander (KSFD 121)
> [mailto:alexander.jesse_at_credit-suisse.com]
> *Sent:* Wednesday, January 31, 2007 4:14 PM
> *To:* dev_at_javaserverfaces.dev.java.net
> *Subject:* RE: Util.componentIsDisabledOrReadonly(UIComponent
> component) Question
>
> 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/>
>