Hi
I think the problem is there is no way to detect when a value has been
submitted.
Of course you have getSubmittedValue(), but there are cases where the value
has
been set and it is null, but you can't detect that fact.
The objective of decode() method is scan request headers or parameters and
then
invoke setSubmittedValue(...) properly. If there is getValue() and
isLocalValueSet(), why don't add isSubmittedValueSet() in the same way?
public void setSubmittedValue(Object submittedValue)
{
setSubmittedValueSet(true);
getStateHelper().put(PropertyKeys.submittedValue, submittedValue );
}
Then, on UIInput.validate(...) we can fix the code, so if there is a
validation
over a non submitted value check for required property and if it is required
declare the request as invalid.
Of course, add a new method in EditableValueHolder is not pretty, but in JSF
2.0 it was added EditableValueHolder.resetValue().
Is the change backward compatible with JSF 2.0/2.2 third party libraries?
Yes, I think so, unless you have a component that does not extend from
UIInput
and implements EditableValueHolder. I prefer that compromise to another
strange
global web config param that will break later.
regards,
Leonardo Uribe
2016-11-30 17:32 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
> Dear Friends of JSF,
>
> The problem is more general than the h:inputSecret validation example.
>
> Instead, consider this example:
>
> <h:inputText id="lastName" required="true"
> value="#{backingBean.lastName}" />
>
> If <input type="text" name="lastName"/> is removed from the DOM prior to
> submitting the form (hack the postback such that the "lastName" request
> parameter is not present), then validation of the lastName value is
> bypassed and the UPDATE_MODEL_VALUES phase will be reached. This is invalid
> because the model will not contain a lastName value (even though the model
> requires it).
>
> To see this problem in action, follow the instructions on this page:
> http://www.liferayfaces.org/web/guest/jsfspec1433
>
> The code that Ed is proposing that we fix (enabled by the proposed
> context-parameter) can be found here:
> https://github.com/javaserverfaces/mojarra/blob/
> master/jsf-api/src/main/java/javax/faces/component/UIInput.java#L991-L993
>
> if (submittedValue == null) {
> return;
> }
>
> Q: Would it cause a backward compatibility problem if we simply made the
> following change?
>
> if ((submittedValue == null) && !isRequired()) {
> return;
> }
>
> In other words, is it necessary to introduce the context-param along with
> the fix?
>
> Thanks,
>
> Neil
>
> > On Nov 30, 2016, at 7:35 AM, Josh Juneau <juneau001_at_gmail.com> wrote:
> >
> > I think that the proposal looks fine, but I agree with Bauke's
> sentiments as this seems like a fairly non-standard use case.
> >
> > Josh Juneau
> > juneau001_at_gmail.com
> > http://jj-blogger.blogspot.com
> > https://www.apress.com/index.php/author/author/view/id/1866
> >
> >
> > On Wed, Nov 30, 2016 at 3:47 AM, arjan tijms <arjan.tijms_at_gmail.com>
> wrote:
> > Hi,
> >
> > An "always run validator when required is true" seems okay to me. I did
> spot a small typo in the text, as it currently says:
> >
> > " If the value of "required" is false, the required attribute is not set
> not set"
> >
> > I assume the second "not set" should not be there.
> >
> > The example is indeed a little peculiar. I assume the user does this to
> avoid having a separate backing bean with an action method that only calls
> "request.authenticate", but becoming authenticated as a side-effect of
> running validation would probably not pass code review in a lot of places I
> think.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> > On Wed, Nov 30, 2016 at 8:21 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> > Hi,
> >
> > Proposal itself looks good, but I can't think of any use case where it
> would be used as a real solution instead of as a workaround to a design
> problem. You?
> >
> > Cheers, B
> >
> > On Tue, Nov 29, 2016 at 6:15 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
> > Hello Volunteers,
> >
> > Neil Griffin brought this issue to my attention [1] and has been ardently
> > advocating for it to be addressed in 2.3.
> >
> > When you say required="true" on a UIInput component, the validation
> > must always take place, even when there is no entry in the request
> > corresponding to that component.
> >
> > Background:
> >
> > Consider this login page:
> >
> > <h:inputText id="userName" required="true"
> > value="#{backingBean.userName}" />
> >
> > <h:inputSecret id="password" required="true"
> > validator="#{backingBean.validatePassword}"
> > value="#{backingBean.password}" />
> >
> > <h:commandButton action="/views/authenticatedUser.xhtml" />
> >
> >
> > If the postback is hacked such that the userName is present as a request
> > parameter, but the password is not, the password validator would be
> > bypassed. If the password validator is used as the entry point to
> > perform authentication, this could cause problems.
> >
> > Now, it must be said that using a validator on a password field as the
> > entry point to perform authentication is a particular design choice.
> > This design choice runs a bit counter to the stated purpose of the
> > validation system, which is to ensure syntactic and some level of
> > semantic validity of fields. There are other ways to perform
> > authentication that do not rely on the validation system for this
> > purpose.
> >
> > Nonetheless, we would like to accomodate this use case.
> >
> > Proposal:
> >
> > For JSF 2.3, I propose the following.
> >
> > Modify PDF section 3.5.4 to read:
> >
> >
> > Spec> *The render-independent property required is a shorthand for the
> > Spec> function of a required validator. If the value of this property is
> > Spec> true, **there is an entry in the request payload corresponding to
> > Spec> this component**, and the component has no value, the component is
> > Spec> marked invalid and a message is added to the FacesContext
> > Spec> instance.*
> >
> >
> > Modify the JavaDoc for UIInput.validate(). Modify the first bullet
> > point to read:
> >
> >
> > Spec> Retrieve the submitted value with getSubmittedValue(). If this
> > Spec> returns null, and the
> > Spec> javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_
> WHEN_REQUIRED_IS_TRUE
> > Spec> context-parameter is set to true (ignoring case), examine the
> > Spec> value of the "required" property. If the value of "required" is
> > Spec> true, continue as below. If the value of "required" is false, the
> > Spec> "required" attribute is not set not set, exit without further
> > Spec> processing. If the context-paramater is not set, or is set to
> > Spec> false (ignoring case) exit without further processing. (This
> > Spec> indicates that no value was submitted for this component.)
> >
> >
> > With these changes, the javadoc for UIInput.validateValue() can remain
> > unchanged.
> >
> > ACTION: Please let us know your thoughts about this by COB 2016-12-06.
> > I really hope you all can accept it as is, but I think the chance for EG
> > discussion is warranted here.
> >
> > Ed
> >
> > --
> > | edward.burns_at_oracle.com | office: +1 407 458 0017
> >
> > [1] https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433
> >
> >
> >
>
>