You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Stephen Friedrich <tr...@eekboom.com> on 2008/06/19 15:44:03 UTC
[Trinidad} defaultCommand of tr:form skips validations
While testing I noticed that my application crashed with an error from the
persistence layer.
I found out that the reason is invalid form data submitted using enter in a
tr:inputText that is contained in a tr:from with a defaultCommand.
Usually that submit should never make it to the action handler because I have
a tr:validateLength that prevents it.
That validator works fine if the submit button is clicked.
However if the user simply hits enter in an input field that VALIDATION IS SKIPPED.
It works fine if I use f:validateLength instead of tr:validateLength, however
there's no client side validation in that case (and the error message is uglier).
I am using Trinidad 1.2.8 with Mojarra 1.2._08-b06 and Facelets 1.1.14.
Here's relevant snippet from my code. I added the f:validateLength just for testing:
<!-- Fax -->
<tr:inputText id="fax" label="#{Output.FAX}" value="#{_currentBranch.fax}" required="true" maximumLength="128">
<tr:validateLength minimum="8" maximum="128"/>
</tr:inputText>
<!-- E-Mail -->
<tr:inputText id="email" label="#{Output.EMAIL}" value="#{_currentBranch.email}" required="true" maximumLength="128">
<tr:validateLength minimum="7" maximum="128"/>
<f:validateLength minimum="7" maximum="128"/>
</tr:inputText>
<!-- Save Button -->
<tr:commandButton id="saveButton"
action="#{branchControllert.save}"
text="Save"/>
See attachments for the different behaviour depending on how the form is submitted.
You can see that the "Fax" input field is not validated at all when the form is
submitted using the default command.
IMHO this should be considered a serious bug, because effectively it removes one layer
of security. I am pretty sure that there are lots of apps out there where checks on the
business and persistence layer are missing.
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Matthias Wessendorf <ma...@apache.org>.
Ho Stephan,
I added a comment to your bug
-M
On Sat, Jun 21, 2008 at 3:42 PM, Stephen Friedrich <tr...@eekboom.com> wrote:
> Hi Matthias,
>
> I created a self-contained example and attached it to the Jira issue.
> Please note that I enabled client validation. You can still reproduce the
> bug by
> simply pressing enter in the field (which skips client validation which is
> another bug).
> (If you disable client validation, the bug can be reproduced by clicking on
> "Save", too.)
>
> Matthias Wessendorf wrote:
>>
>> Hi,
>>
>> I just checked a very simple example (see bug)
>> and couldn't notice the problem
>>
>> On Fri, Jun 20, 2008 at 1:39 AM, Stephen Friedrich <tr...@eekboom.com>
>> wrote:
>>>
>>> Thanks, I created a Jira issue for the main error:
>>> https://issues.apache.org/jira/browse/TRINIDAD-1129
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Stephen Friedrich <tr...@eekboom.com>.
Hi Matthias,
I created a self-contained example and attached it to the Jira issue.
Please note that I enabled client validation. You can still reproduce the bug by
simply pressing enter in the field (which skips client validation which is
another bug).
(If you disable client validation, the bug can be reproduced by clicking on "Save", too.)
Matthias Wessendorf wrote:
> Hi,
>
> I just checked a very simple example (see bug)
> and couldn't notice the problem
>
> On Fri, Jun 20, 2008 at 1:39 AM, Stephen Friedrich <tr...@eekboom.com> wrote:
>> Thanks, I created a Jira issue for the main error:
>> https://issues.apache.org/jira/browse/TRINIDAD-1129
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Stephen Friedrich <tr...@eekboom.com>.
Nope, definitely not working, even with a single input text (plus submit button).
See jira.
Anything else I can do to pinpoint the bug?
Stephen Friedrich wrote:
> Hi Matthias,
> that's very, very strange.
> I'm going to try with that minimal example, too.
> However I am very sure that it is not working for me with my actual pages.
> Do you know any configuration/settings that may influence this?
> Do you know where the "minimum" and "maximum" fields of the JSF base
> class validator are restored
> (for example can you set a breakpoint on the corresponding setters of
> the base class and have
> a look from where they are called)?
>
> Thanks for your assistance!
>
> Matthias Wessendorf wrote:
>> Hi,
>>
>> I just checked a very simple example (see bug)
>> and couldn't notice the problem
>
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Stephen Friedrich <tr...@eekboom.com>.
Hi Matthias,
that's very, very strange.
I'm going to try with that minimal example, too.
However I am very sure that it is not working for me with my actual pages.
Do you know any configuration/settings that may influence this?
Do you know where the "minimum" and "maximum" fields of the JSF base class validator are restored
(for example can you set a breakpoint on the corresponding setters of the base class and have
a look from where they are called)?
Thanks for your assistance!
Matthias Wessendorf wrote:
> Hi,
>
> I just checked a very simple example (see bug)
> and couldn't notice the problem
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
I just checked a very simple example (see bug)
and couldn't notice the problem
On Fri, Jun 20, 2008 at 1:39 AM, Stephen Friedrich <tr...@eekboom.com> wrote:
> Thanks, I created a Jira issue for the main error:
> https://issues.apache.org/jira/browse/TRINIDAD-1129
>
> I haven't made any progress in finding out how state stored in the super
> class is meant to be restored.
> As a workaround I made my own validator (which isn't too hard because I
> don't have to support JSP nor i18n).
>
> Matthias Wessendorf wrote:
>>
>> Since I am on trainings today/tomorrow, I will comeback to this
>> possible already over the weekend...
>>
>> Greetings,
>> Matthias
>>
>> On Thu, Jun 19, 2008 at 11:43 AM, Stephen Friedrich
>> <tr...@eekboom.com> wrote:
>>>
>>> Thanks Matthias for the answer.
>>> I spent a couple more hours on it.
>>> Looks like there are two problems:
>>>
>>> - Client side validation is not run when form is submitted via
>>> defaultCommand:
>>> That is https://issues.apache.org/jira/browse/TRINIDAD-695 and that
>>> issue
>>> contains some suggestions for a fix.
>>>
>>> The second bug is much more serious, because it leaves the server without
>>> any
>>> validation.
>>>
>>> - tr:validateLength (and very probably also the other validators that
>>> extend
>>> the
>>> standard validators like tr:validateDoubleRange) don't validate anything
>>> on
>>> the
>>> server at all when used with mojarra.
>>> This bug is very similar to one I reported earlier, and that you helped
>>> me
>>> get resolved:
>>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641
>>> At first I checked wether that fix is still in mojarra 1.2_08, but that
>>> is
>>> ok.
>>> However Trinidad no longer restored the minimum and maximum fields of
>>> the
>>> base
>>> class javax.faces.validator.LengthValidator.
>>> So far I have no idea where those values should get restored:
>>> PropertyKey.restoreValue() and StateUtils.restoreState() seemed good
>>> candidates
>>> but I can't see any (reflective?) call (to setters) anywhere.
>>> Any idea?
>>> And generally: Is there any explanation how state saving is supposed to
>>> work
>>> with Trinidad? The javadoc is a little scarce.
>>>
>>> IMHO the cleaner way would be to not extend the standard validators at
>>> all.
>>> There isn't much code reuse going on anyway and it seems to be too
>>> fragile
>>> (currently broken for the second time).
>>>
>>>
>>> Matthias Wessendorf wrote:
>>>>
>>>> Perhaps I have time to check on the weekend.
>>>> There is already a bug like this in jira. Patches
>>>> are welcome too.
>>>>
>>>> On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich
>>>> <tr...@eekboom.com>
>>>> wrote:
>>>>>
>>>>> While testing I noticed that my application crashed with an error from
>>>>> the
>>>>> persistence layer.
>>>>> I found out that the reason is invalid form data submitted using enter
>>>>> in
>>>>> a
>>>>> tr:inputText that is contained in a tr:from with a defaultCommand.
>>>>>
>>
>>
>>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Stephen Friedrich <tr...@eekboom.com>.
Thanks, I created a Jira issue for the main error:
https://issues.apache.org/jira/browse/TRINIDAD-1129
I haven't made any progress in finding out how state stored in the super
class is meant to be restored.
As a workaround I made my own validator (which isn't too hard because I
don't have to support JSP nor i18n).
Matthias Wessendorf wrote:
> Since I am on trainings today/tomorrow, I will comeback to this
> possible already over the weekend...
>
> Greetings,
> Matthias
>
> On Thu, Jun 19, 2008 at 11:43 AM, Stephen Friedrich
> <tr...@eekboom.com> wrote:
>> Thanks Matthias for the answer.
>> I spent a couple more hours on it.
>> Looks like there are two problems:
>>
>> - Client side validation is not run when form is submitted via
>> defaultCommand:
>> That is https://issues.apache.org/jira/browse/TRINIDAD-695 and that issue
>> contains some suggestions for a fix.
>>
>> The second bug is much more serious, because it leaves the server without
>> any
>> validation.
>>
>> - tr:validateLength (and very probably also the other validators that extend
>> the
>> standard validators like tr:validateDoubleRange) don't validate anything on
>> the
>> server at all when used with mojarra.
>> This bug is very similar to one I reported earlier, and that you helped me
>> get resolved:
>> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641
>> At first I checked wether that fix is still in mojarra 1.2_08, but that is
>> ok.
>> However Trinidad no longer restored the minimum and maximum fields of the
>> base
>> class javax.faces.validator.LengthValidator.
>> So far I have no idea where those values should get restored:
>> PropertyKey.restoreValue() and StateUtils.restoreState() seemed good
>> candidates
>> but I can't see any (reflective?) call (to setters) anywhere.
>> Any idea?
>> And generally: Is there any explanation how state saving is supposed to
>> work
>> with Trinidad? The javadoc is a little scarce.
>>
>> IMHO the cleaner way would be to not extend the standard validators at all.
>> There isn't much code reuse going on anyway and it seems to be too fragile
>> (currently broken for the second time).
>>
>>
>> Matthias Wessendorf wrote:
>>> Perhaps I have time to check on the weekend.
>>> There is already a bug like this in jira. Patches
>>> are welcome too.
>>>
>>> On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich <tr...@eekboom.com>
>>> wrote:
>>>> While testing I noticed that my application crashed with an error from
>>>> the
>>>> persistence layer.
>>>> I found out that the reason is invalid form data submitted using enter in
>>>> a
>>>> tr:inputText that is contained in a tr:from with a defaultCommand.
>>>>
>
>
>
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Matthias Wessendorf <ma...@apache.org>.
Since I am on trainings today/tomorrow, I will comeback to this
possible already over the weekend...
Greetings,
Matthias
On Thu, Jun 19, 2008 at 11:43 AM, Stephen Friedrich
<tr...@eekboom.com> wrote:
> Thanks Matthias for the answer.
> I spent a couple more hours on it.
> Looks like there are two problems:
>
> - Client side validation is not run when form is submitted via
> defaultCommand:
> That is https://issues.apache.org/jira/browse/TRINIDAD-695 and that issue
> contains some suggestions for a fix.
>
> The second bug is much more serious, because it leaves the server without
> any
> validation.
>
> - tr:validateLength (and very probably also the other validators that extend
> the
> standard validators like tr:validateDoubleRange) don't validate anything on
> the
> server at all when used with mojarra.
> This bug is very similar to one I reported earlier, and that you helped me
> get resolved:
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641
> At first I checked wether that fix is still in mojarra 1.2_08, but that is
> ok.
> However Trinidad no longer restored the minimum and maximum fields of the
> base
> class javax.faces.validator.LengthValidator.
> So far I have no idea where those values should get restored:
> PropertyKey.restoreValue() and StateUtils.restoreState() seemed good
> candidates
> but I can't see any (reflective?) call (to setters) anywhere.
> Any idea?
> And generally: Is there any explanation how state saving is supposed to
> work
> with Trinidad? The javadoc is a little scarce.
>
> IMHO the cleaner way would be to not extend the standard validators at all.
> There isn't much code reuse going on anyway and it seems to be too fragile
> (currently broken for the second time).
>
>
> Matthias Wessendorf wrote:
>>
>> Perhaps I have time to check on the weekend.
>> There is already a bug like this in jira. Patches
>> are welcome too.
>>
>> On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich <tr...@eekboom.com>
>> wrote:
>>>
>>> While testing I noticed that my application crashed with an error from
>>> the
>>> persistence layer.
>>> I found out that the reason is invalid form data submitted using enter in
>>> a
>>> tr:inputText that is contained in a tr:from with a defaultCommand.
>>>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Stephen Friedrich <tr...@eekboom.com>.
Thanks Matthias for the answer.
I spent a couple more hours on it.
Looks like there are two problems:
- Client side validation is not run when form is submitted via defaultCommand:
That is https://issues.apache.org/jira/browse/TRINIDAD-695 and that issue
contains some suggestions for a fix.
The second bug is much more serious, because it leaves the server without any
validation.
- tr:validateLength (and very probably also the other validators that extend the
standard validators like tr:validateDoubleRange) don't validate anything on the
server at all when used with mojarra.
This bug is very similar to one I reported earlier, and that you helped me
get resolved:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=641
At first I checked wether that fix is still in mojarra 1.2_08, but that is ok.
However Trinidad no longer restored the minimum and maximum fields of the base
class javax.faces.validator.LengthValidator.
So far I have no idea where those values should get restored:
PropertyKey.restoreValue() and StateUtils.restoreState() seemed good candidates
but I can't see any (reflective?) call (to setters) anywhere.
Any idea?
And generally: Is there any explanation how state saving is supposed to work
with Trinidad? The javadoc is a little scarce.
IMHO the cleaner way would be to not extend the standard validators at all.
There isn't much code reuse going on anyway and it seems to be too fragile
(currently broken for the second time).
Matthias Wessendorf wrote:
> Perhaps I have time to check on the weekend.
> There is already a bug like this in jira. Patches
> are welcome too.
>
> On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich <tr...@eekboom.com> wrote:
>> While testing I noticed that my application crashed with an error from the
>> persistence layer.
>> I found out that the reason is invalid form data submitted using enter in a
>> tr:inputText that is contained in a tr:from with a defaultCommand.
>>
Re: [Trinidad} defaultCommand of tr:form skips validations
Posted by Matthias Wessendorf <ma...@apache.org>.
Perhaps I have time to check on the weekend.
There is already a bug like this in jira. Patches
are welcome too.
On Thu, Jun 19, 2008 at 6:44 AM, Stephen Friedrich <tr...@eekboom.com> wrote:
> While testing I noticed that my application crashed with an error from the
> persistence layer.
> I found out that the reason is invalid form data submitted using enter in a
> tr:inputText that is contained in a tr:from with a defaultCommand.
>
> Usually that submit should never make it to the action handler because I
> have
> a tr:validateLength that prevents it.
>
> That validator works fine if the submit button is clicked.
> However if the user simply hits enter in an input field that VALIDATION IS
> SKIPPED.
> It works fine if I use f:validateLength instead of tr:validateLength,
> however
> there's no client side validation in that case (and the error message is
> uglier).
>
> I am using Trinidad 1.2.8 with Mojarra 1.2._08-b06 and Facelets 1.1.14.
>
> Here's relevant snippet from my code. I added the f:validateLength just for
> testing:
>
> <!-- Fax -->
> <tr:inputText id="fax" label="#{Output.FAX}"
> value="#{_currentBranch.fax}" required="true" maximumLength="128">
> <tr:validateLength minimum="8" maximum="128"/>
> </tr:inputText>
>
> <!-- E-Mail -->
> <tr:inputText id="email" label="#{Output.EMAIL}"
> value="#{_currentBranch.email}" required="true" maximumLength="128">
> <tr:validateLength minimum="7" maximum="128"/>
> <f:validateLength minimum="7" maximum="128"/>
> </tr:inputText>
>
> <!-- Save Button -->
> <tr:commandButton id="saveButton"
> action="#{branchControllert.save}"
> text="Save"/>
>
> See attachments for the different behaviour depending on how the form is
> submitted.
> You can see that the "Fax" input field is not validated at all when the form
> is
> submitted using the default command.
>
> IMHO this should be considered a serious bug, because effectively it removes
> one layer
> of security. I am pretty sure that there are lots of apps out there where
> checks on the
> business and persistence layer are missing.
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org