Isn't the behavior now to block updating components marked readonly or
disabled?
-----
Jason Lee, SCJP
Programmer/Analyst
http://www.iec-okc.com
> -----Original Message-----
> From: Adam Winer [mailto:adam.winer_at_oracle.com]
> Sent: Wednesday, January 31, 2007 4:48 PM
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: Util.componentIsDisabledOrReadonly(UIComponent
> component) Question
>
> 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/>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>