[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467393 ] David Chandler commented on MYFACES-1467: - Has the spec already been amended to address this issue? Section 3.5.5 on validator implementation now reads Unless otherwise specified, components with a null local value cause the validation checking by this Validator to be skipped. If a component should be required to have a non-null value, a component attribute with the name required and the value true must be added to the component in order to enforce this rule. I don't remember the second sentence being there before. At any rate, I agree that the spec doesn't resolve the conflict between required=true and disabled/readonly=true in the case of null values. The root issue appears to be that the spec overloads the meaning of a null submitted value. At validation time, there is currently no way to distinguish between a null value from the user and a null value because the component is readonly or disabled. Besides causing the issue at hand, it masks a parameter tampering attack (changing the value of a readonly or disabled component), which is also of security interest. So the spec needs to 1. Discontinue overloading the meaning of a null submitted value (perhaps by the introduction of new properties to UIInput) and 2. Explicitly address the conflict between required and readonly / disabled for null values Are we agreed on this? Are there other proposals? In the mean time, can we leave the issue open until the spec issue is resolved? JSF security issues need to be addressed, and if users begin to depend on insecure behavior (as they have been), it will only be that much harder to fix later. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt, patch2.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Chandler updated MYFACES-1467: Status: Patch Available (was: Reopened) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464501 ] David Chandler commented on MYFACES-1467: - Jeff, Cristi, you're absolutely right. There is no conflict between the required and disabled/readonly attributes--that's what I get for posting after a long week in another time zone. It is possible to preserve the prior security benefit as well as restore the old behavior, and I've provided patch2.txt to that end. In order to beef up the validate() method, I added isDisabled() and isReadonly() methods which read from the special component attributes map since not all UIInput components have the readonly and disabled properties. At first, I was concerned that parameter tampering might be possible when disabled or readonly is true; however, this is prevented by HtmlRendererUtils.decodeUIInput, which doesn't set the submitted value if the component is disabled or readonly, which is no doubt why the unamended spec said that validation implementations should skip validation if the submitted value is null. In essence, JSF has always ignored user input for disabled and readonly components, and the new patch preserves that behavior, while still preventing parameter tampering if a required value is missing from a component that is enabled for editing (i.e., not readonly or disabled). Please give patch2 a whirl. I confirmed that I do not get validation errors when using both required=true and disabled=true. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Chandler updated MYFACES-1467: Status: Open (was: Patch Available) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Chandler updated MYFACES-1467: Status: Patch Available (was: Open) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt, patch2.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ https://issues.apache.org/jira/browse/MYFACES-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464106 ] David Chandler commented on MYFACES-1467: - Cristi, Good catch. Just to clarify, you're saying what's broken is that you can no longer use required=true and disabled=true together, correct? I'm actually surprised this ever worked, as these two attributes would seem in conflict with each other. Conceptually, if an input component is disabled, validation can be skipped, so the conditions could be added; however, the spec does not exempt validation from occurring in the case of disabled or readonly, whereas it explicitly states that required=true with a null value should result in an error. Therefore, a strict reading of the spec would seem to indicate that required=true and disabled=true should in fact result in a validation error because required=true implicitly takes precedence. Having said that, I'm OK with adding conditions to skip validation for disabled or readonly components even when required=true, as this was the de facto behavior before this fix. I understand now how a submitted value of null is special. Rather than put in explicit checks to call validation only when a field is editable (not disabled or readonly), the current code relies on the fact that the submitted value is null in these cases, and therefore validation is skipped. Whether this was by design or by accident, I wonder. Interestingly, UIInput.processValidators() method skips validation if the component is not rendered. Perhaps we should add checks for disabled and readonly in the same method, as validate() needn't even be called if these attributes are true. I guess it all depends on how strictly we interpret the spec regarding the required attribute. As for where we put the conditions, that depends on whether it ever possible for a disabled or readonly component to have a non-null submitted value. Does anyone know? /dmc Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: https://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Fix For: 1.1.5-SNAPSHOT Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Option for NavigationHandler to support viewIds as outcome
Don't forget that returning view IDs in outcomes will break tool support such as the visual page flow designer in Exadel Studio. Even without tools, I find it extremely helpful as a developer to be able to look in one place to see how the application flows. The proposed capability would make that impossible, so I agree with Craig and Arash that returning view IDs in outcomes is unsuitable for apps that will be maintained by multiple developers. Having worked as one of 30+ developers on a large application (2000 views) written in a scripting language that effectively returned view IDs in outcomes, I can testify to the horrors of code maintenance with this approach. Introducing finite state machine navigation into that code base and moving nav rules to config files has made it much easier to work on. David ChandlerJSF Consultant / Trainerlearnjsf.comOn 10/30/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote:It is much easier for a developer (especially if they are beginners in JSF) to return name of the page instead of event occurred in page (logical outcome) as output. There are some bad development practices, which when a developer get used to them, it is hard to forget, I think this feature is one of them.since this bad practice(same reasons as described by Craig), makes life easier for them, when they have this feature they will get addicted to it, and they won't learn the real idea behind outcomes. I think this is like giving marijuana to JSF developers! Like the cartoon in the theserverside.com about AOP considered harmful ;-) RegardsArashOn 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig,It's all about convention over configuration, and this concept is inturn very good for maintenance. Writing unnecessary configuration codeisn't.Let's look at an automatic navigation handler in practice: 1) I have a managed-bean action-method which returns overview andthis means, I'll go to overview.jsp2) I want to change this to go to overview_2.jsp3) so I won't change anything in the managed-bean-method, but create a new navigation-rule (in your case, I'd need to change thenavigation-rule - where is the maintenance difference, I don't touchmy managed-bean?)4) If I want to go to somewhere else from any other page, I'll need to create additional navigation-rules, according to the concept of JSF.Essence is - you don't have to change anything in your managed bean,youjust add configuration rules where necessary, but keep them out where unnecessary.regards,MartinOn 10/30/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 10/30/06, Martin Marinschek [EMAIL PROTECTED] wrote: Hi Craig, you have been argumenting into this direction before, and I'm sorry to disagree completely. What JSF does in the standard is good for projects where you have this necessity of different roles for page development and back-end development. It's not a matter of different roles.The design principles I advocate are the same whether there is one developer performing multiple roles, or different developers (or developer groups) performing the different roles. The architectural issues here are exactly the same in either case. Generally - for small projects, and the majority of web-projects are still small projects, the person writing the navigation-handling code, the page, and the backing-bean will be the same, so why not give them the ability to have a convention-over-configuration approach? You can always override convention-over-configuration by supplying configuration! Because that user will be crying alligator tears a year from now, or a month from now, when the person responsible for the overall organization of the webapp changes the set of view identifiers that represents the UI of an app.WHY SHOULD THIS REQUIRE CHANGES IN THE BUSINESS LOGIC???.That is a cross-linkage between view tier and model tier that I find unacceptable in large scale apps. You have a seductive argument with respect to small scale apps.But I can tell you from 30 years of professional software development experience that managers tend to buy in to this kind of attitude at the prototype stage, when ongoing application maintenance is not a consideration.And those types of people tend to be really unhappy when the effects of this type of decision cause their maintenance budgets to skyrocket.The scale of the app does not actually matter -- the percentage of the overall budget that must be allocated to reworking previously running code is *always* a major consideration. Furthermore, I seem to resemble that in the discussion about annotations you've made the same proposal as Ernst has at the beginning of this discussion - writing a custom navigation-handler which enables one to optionally not configure navigations, and not handle navigation via annotations. I am *adamantly* in the no annotations for navigaiton camp ... navigation is absolutely *not* something that should be done with annotations.Doing so would have the same
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[
http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12443261
]
David Chandler commented on MYFACES-1467:
-
I suspect there are still other issues here, but to get the immediate security
problem resolved, I will proceed with Adam's suggestion to patch the decode()
method of the TextInput Renderer. It turns out that
HtmlRendererUtils.decodeUIInput() is logging a warning when it detects the
missing client_id in the request, but is taking no further action. It seems
this would be a fine place to set the submitted value to the empty string so as
to trigger requiredness validation. Thoughts?
if(paramMap.containsKey(clientId))
{
((EditableValueHolder) component).setSubmittedValue(paramMap
.get(clientId));
}
else
{
log.warn(
There should always be a submitted value for an input if it
+ is rendered, its form is submitted, and it is not disabled
+ or read-only. Component : +
RendererUtils.getPathToComponent(component));
}
Thanks,
/dmc
Validation doesn't run for required fields if submitted value is null
-
Key: MYFACES-1467
URL: http://issues.apache.org/jira/browse/MYFACES-1467
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT
Reporter: David Chandler
Assigned To: Matthias Weßendorf
Attachments: patch.txt
A component with a required value will not fail validation as expected if the
submitted value is null. This issue is not seen normally because browsers
send the value for an empty text field as an empty string. That is, the POST
data for an empty field1 will contain the field name but no value, like
field1=field2=something. However, if you use a man-in-the-middle proxy such
as Paros to remove fieldname= from the POST data, the submitted value will
be null. UIInput.validate() skips validation for null submitted values, but
since requiredness is also part of validation, the requiredness check gets
skipped, too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12443147 ] David Chandler commented on MYFACES-1467: - Alas, I am in anguish, Adam. I do not see how the proposed patch violates the spec. If a submitted value is null and the field is required, the patched line will not return immediately as before, but it will proceed to validateValue(), which does indeed return for empty (null or zero-length) values without calling a validator. Perhaps the validateValue() method would be better named callValidatorIfNotEmpty(), because that's what it actually does. Further, the CURRENT code does NOT meet spec section 3.5.4 for the case I have demonstrated. I don't know how the TCK works, but I highly doubt it's simulating a MITM tool to test compliance with section 3.5.4. From a security point of view, the MITM case is really the only one that matters. I'm in banking, and we do this kind of penetration testing routinely, so it is important to me that MyFaces is 100% secure against MITM attacks. I have thus far been very pleased with MyFaces as this is the only vulnerability of its kind (parameter tampering) which I have found in the code to date, and I am doing my best to help maintain its quality. Thank you, /dmc Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442593 ] David Chandler commented on MYFACES-1467: - Thanks everyone for your contributions. If I may summarize Craig's comments, skipping validation for a null value is a good thing, whereas skipping requiredness check for a null value is not. Correct? Adam, the approach of fixing it only in h:inputText renderer gives me concern because it leaves this issue hanging for any custom components people write (and possibly others of the base components). You can use an MITM proxy to wipe a submitted value for any component, not just h:inputText. Therefore, I'd really rather fix it in UIInput once for all. Can you elaborate on your concerns with this approach? As to a cross-field validation framework, I have successfully used the approach of creating a component my:formValidator validator=id or bean.method. You put it as the last field in a form, and the component internally does a setSubmittedValue(NO_OP) so as to force the validation method specified in the attribute to run. I'd be happy to contribute my 3-line component to Tomahawk if desired :-) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442354 ] David Chandler commented on MYFACES-1467: - Thanks for thinking this over, Cagatay and Matthias. The more I think about this, the less I think it's a spec issue, after all. In the case of the MITM exploit, neither MyFaces nor RI currently meet the requirement of section 3.5.4 of the spec, which states If the value of this property [required] is true and the component has no value, the component is marked invalid and a message is added... Section 3.5.5 immediately following begins with the caveat Unless otherwise specified Well, section 3.5.4 does in fact otherwise specify. Given the proximity of these sections, I find it likely that 3.5.4 is exactly what 3.5.5 has in mind, so there is no problem with the spec at all. Even if the sections were in conflict, I would think it a much more serious problem to ignore the required attribute than to call validation with a null value. One is an optimization, the other a security flaw. The code in UIInput.validateValue() method does exactly what 3.5.4 and 3.5.5 say it should do, but the patched line of code as it currently exists defeats the good code in validateValue() by not calling it for a null submitted value, even if the field is required. The patch simply ensures that the already-correct validateValue() method will run if the component is required. So, I go back to my position that the code in question is a security bug and also not compliant with the spec for this case. If we apply the patch, the only time users would ever see a difference between the RI and MyFaces is when using an MITM proxy. And of course, I'll be submitting this to RI, as well. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5-SNAPSHOT, 1.2.0-SNAPSHOT Reporter: David Chandler A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=all ] David Chandler updated MYFACES-1467: Status: Patch Available (was: Open) Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1467) Validation doesn't run for required fields if submitted value is null
[ http://issues.apache.org/jira/browse/MYFACES-1467?page=comments#action_12442266 ] David Chandler commented on MYFACES-1467: - Agreed in part. It's actually a bug in the spec due to these conflicting requirements: Section 3.5.4 (Validation Processing) of the 1.1 spec states: The reader-independent property required is a shorthand for the function of a required validator. If the value of this property is true and the component has no value, the component is marked invalid and a message is added... This requirement is not met in the current impl when using a proxy tool or other mechanism to remove the name-value pair from the POST data. However, section 3.5.5 (Standard Validator Implementations) says: Unless otherwise specified, components with a null local value cause the validation checking by this validator to be skipped. If you consider requiredness checking to be part of validation as the spec does, then these two sections are in conflict. The current code skips validation for null value as section 3.5.5 prescribes, but in doing so violates the requirement of 3.5.4, which results in the undesirable behavior that a required field may be omitted without detection simply by removing it altogether from the POST. Matthias and I worked on this together this afternoon at ApacheCon, so I expect him to post some more details shortly. Validation doesn't run for required fields if submitted value is null - Key: MYFACES-1467 URL: http://issues.apache.org/jira/browse/MYFACES-1467 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.0-SNAPSHOT, 1.1.5-SNAPSHOT Reporter: David Chandler Assigned To: Matthias Weßendorf Attachments: patch.txt A component with a required value will not fail validation as expected if the submitted value is null. This issue is not seen normally because browsers send the value for an empty text field as an empty string. That is, the POST data for an empty field1 will contain the field name but no value, like field1=field2=something. However, if you use a man-in-the-middle proxy such as Paros to remove fieldname= from the POST data, the submitted value will be null. UIInput.validate() skips validation for null submitted values, but since requiredness is also part of validation, the requiredness check gets skipped, too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Any myFaces presentations at ApacheCon US this year?
Hello, Just wondering if there is any interest in myFaces at ApacheCon US in Oct. The Call for Papers (http://www.us.apachecon.com/html/cfp-form.html) doesn't seem to have a topic for it unless it's under the ASF umbrella? I've done some work on Internet banking software to secure myFaces against the oWASP Top Ten attacks (especially forced browsing prevention and paramter tampering / information hiding in menu options).Is anyoneinterested in meeting to discuss JSF security at ApacheConUS? David Chandler Java Web Developer
