update_item fails with data format error in Faraday

[sshipway]

Describe the bug

The update_item() call fails, as the supplied data format is wrong

• The specified content-type, although strictly correct with regard to RFC6902, causes the Farady library to stop json-encoding
• The API requires an array of changes, but the function only provides a single change

To Reproduce

Try updating an item via the SDK, such as using

      item = op.update_item(
        vault_id: vaultid,
        id: itemid,
        op: 'replace', path: path, value: newpass
      )

This fails with "undefined method `bytesize'"

Expected behavior

The call should return cleanly with an updated object

Environment

• Gem version: 0.1.3
• Ruby version: 2.7

Additional context

The problem is here in client/items.rb -

def update_item(vault_id:, id:, **attributes)
    Item.new patch("vaults/#{vault_id}/items/#{id}", body: attributes, headers: {"Content-Type": "application/json-patch+json"}).body
end

The content-type header causes Faraday library to skip the JSON encoding which results in the error. Although this header is supposedly necessary according to the RFC in fact it is not required by the 1Password API.

In addition, though, the API expects the changes (in the body) to be a list. However as attributes comes from the remaining named parameters this is not possible

A solution is to instead use:

def update_item(vault_id:, id:, **attributes)
   Item.new patch("vaults/#{vault_id}/items/#{id}", body: [ attributes ], headers: {}).body
end

This converts the attributes into the required array, and returns to the default content-type (JSON) which is properly encoded by the Faraday library.

Tested Faraday library versions
faraday (1.10.0)
faraday-em_http (1.0.0)
faraday-em_synchrony (1.0.0)
faraday-excon (1.1.0)
faraday-httpclient (1.0.1)
faraday-multipart (1.0.3)
faraday-net_http (1.0.1)
faraday-net_http_persistent (1.2.0)
faraday-patron (1.0.0)
faraday-rack (1.0.0)
faraday-retry (1.0.3)
faraday_middleware (1.2.0)

[sshipway]

Pull request #9 provided for this fix