Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1, 2.2
    • Fix Version/s: None
    • Component/s: Ajax/JavaScript
    • Labels:
      None

      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.

        Activity

        Hide
        Ed Burns added a comment -

        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

        Show
        Ed Burns added a comment - 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
        Hide
        frederickkaempfer added a comment -

        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.

        Show
        frederickkaempfer added a comment - 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.
        Hide
        kithouna added a comment -

        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?

        Show
        kithouna added a comment - 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?
        Hide
        Ed Burns added a comment -

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

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          People

          • Assignee:
            Unassigned
            Reporter:
            frederickkaempfer
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: