[JAVASERVERFACES_SPEC_PUBLIC-1146] Required fields can be skipped on form submission Created: 21/Nov/12  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File requiredValidation.tar.bz2    

 Description   

With JSF2's ajax features it is possible to specify a list of execute ids that should be considered on ajax form submission. With jsf.ajax.request the execute ids can be specified solely on the client side. This may cause problems when fields are set to required and the action method of - for example - a command button relies on them being filled out. Skipping them may lead to invalid data being saved in a database.

Similarly other fields can be skipped that would require a minimum length or other validations not allowing for empty values.

This is not limited to the ajax case, because every command component can be executed in ajax mode by using the jsf.ajax.request function on the client side.

JSF should provide a way to enforce the presence of fields on a partial request before executing a button's action method. This could be done by checking if the current ajax request is really triggered by one of the f:ajax tags attached to the command object by comparing the execute ids. To enable this behavior for example a "strictAjax" attribute could be added to h:commandButton / h:commandLink and similar components or a new tag f:strictAjax could be created.

A workaround is to verify the execute ids in the action method (FacesContext.getCurrentInstance().getPartialViewContext().getExecuteIds().contains("requiredForm").

I have attached a project that demonstrates the issue.



 Comments   
Comment by Ed Burns [ 21/Nov/12 ]

Before I invest the time to fully understand this, can you take a look at JAVASERVERFACES_SPEC_PUBLIC-1129 and see if it is related?

Ed

Comment by frederickkaempfer [ 21/Nov/12 ]

It is unrelated. This is a pure security/data integrity concern where JSF gives the client a bit too much control over the execution of the lifecycle.

Comment by kithouna [ 05/Mar/13 ]

This sounds a bit like the reverse of Rail's mass assignment vulnerability. Instead of blindly accepting data from input that was not rendered, this doesn't bark when data that should be there is not provided?

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Generated at Fri Sep 04 22:36:17 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.