users@javaserverfaces-spec-public.java.net

[jsr372-experts mirror] [jsr372-experts] Re: Re: [1433-UIInputRequiredTrue] PROPOSAL

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Wed, 30 Nov 2016 10:47:14 +0100

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
>>
>
>