Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-7926

rest2ldap: PATCH succeeds or fails depending on field order in JSON data

    XMLWordPrintable

    Details

    • Bug
    • Status: Dev backlog
    • Major
    • Resolution: Unresolved
    • 7.1.0
    • None
    • rest
    • None

      Description

      This issue has been found by Cedric Tran-Xuan when investigating random failures of the unit tests testPatchReplaceWholeObject() and testPatchReplacePartialObject() from the NameAndOptionalJsonReferenceTest class.

      Scenario

      Let's look at testPatchReplaceWholeObject() test in isolation.

      Success scenario

      We are issuing a patch operation to "/tenants/tenant1/users/test1" and we are patching the social resource reference property by providing _id, _rev and an optional JSON field. Here is the patch data that makes this tests succeed:

      {
         "social":[
            {
               "_id":"test3",
               "_rev":"33333",
               "_refProperties":{
                  "_id":1,
                  "type":"coworker"
               }
            },
            {
               "_id":"test2",
               "_rev":"22222",
               "_refProperties":{
                  "_id":2,
                  "type":"friend"
               }
            }
         ],
         "orderedSocial":{
            "_id":"test5",
            "_rev":"55555",
            "_refProperties":{
               "order":1
            }
         }
      }
      

      Failure scenario

      If we invert the _id _rev fields in the social objects like this:

         "social":[
            {
               "_rev":"33333",
               "_id":"test3",
               "_refProperties":{
                  "_id":1,
                  "type":"coworker"
               }
            },
            {
               "_rev":"22222",
               "_id":"test2",
               "_refProperties":{
                  "_id":2,
                  "type":"friend"
               }
            }
         ],
      

      then the test fails with:

      org.forgerock.json.resource.BadRequestException: The create request cannot be processed because it attempts to create the read-only field '/social/_rev'
      

      Indeed, in the rest2ldap mapping, _rev is the etag and it is flagged as being read_only

      Acceptance criteria

      We should either reject this PATCH request, or process it successfully.

       

      Matthew Swift thinks that this PATCH request process successfully as long as the read-only value matches the value in the resource:

      I agree this doesn't look correct to me. IIRC, it is possible to specify read only values but they must match the existing value.

        Attachments

          Activity

            People

            Unassigned Unassigned
            JnRouvignac Jean-Noël Rouvignac
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated: