kriszyp / json-schema Goto Github PK

RFC 6570 provides a better way to handle undefined variables in URI templates (among other things).

There is a folder present that contains the draft 4 schema, but the validation code only validates objects against schemas by the draft 3 rules.

['a','b','b'] should fail against schema { type:'array', uniqueItems:true} but there is no checking of uniqueItems in the library.

Can you please mention the version of BSD license for the module?

To me it looks like it does not do anything at all (I tried node 0.4.2 with validate.js from the lib folder).

$ node schema_problem.js 
{ valid: true, errors: [] }
{ valid: true, errors: [] }

Here is the slightly modified sample code:

var validate = require('../deps/json_schema/validate').validate;

var data = {name: "Test"};
var schema = {
  properties: {
     name: {type: "string"},
     age: {type: "number"}
  }
};

var validation = validate(data, schema);
console.log(validation);

data.age = 30;
var validation = validate(data, schema);
console.log(validation);

Looks like the files property (https://docs.npmjs.com/files/package.json#files) is not used in package.json to specify the included files, nor is the .npmignore file (https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package) is being used for blacklisting unwanted files, for the package published to npm.

Would you consider adding either the files property or the .npmignore file, so that the resulting package file would have smaller size?

The current size can be seen when executing the command npm pack (https://docs.npmjs.com/cli/pack).

This issue was create via tawata

validating the core schema [validate(schema)] causes validate to choke on the '$schema' instance property; [validate(schema,schema)], which should be equivalent, adds an extra 'null' entry to the result. Deleting the $schema property before validating results in a single 'null' in result.errors.

Here's my test script reproducing the problem:

var schema = require('document/document').tmp['http://json-schema.org/draft-03/schema'];


var v = require('document/validate');
var sys = require('sys');
var result;

sys.debug('----- SCHEMA ----- \n'+sys.inspect(schema));
sys.debug('\n\n');

sys.debug('----- VALIDATE: -----');

result = v.validate(schema);
sys.debug('result = v.validate(schema);'); // should validate
sys.debug('----- RESULT 1 ----- \n'+sys.inspect(result));

result = v.validate(schema, schema); // should be equiv. to 1.
sys.debug('result = v.validate(schema, schema);');
sys.debug('----- RESULT 2 ----- \n'+sys.inspect(result));

delete schema['$schema'];
result = v.validate(schema); // no schema to validate against
sys.debug('result = v.validate(schema);');
sys.debug('----- RESULT 3 ----- \n'+sys.inspect(result));

result = v.validate(schema, schema); // should validate
sys.debug('result = v.validate(schema, schema);');
sys.debug('----- RESULT 4 ----- \n'+sys.inspect(result));

and here's the result of running it:

DEBUG: ----- SCHEMA ----- 
{ '$schema': 'http://json-schema.org/draft-03/schema#'
, id: 'http://json-schema.org/draft-03/schema#'
, type: 'object'
, properties: 
   { type: 
      { type: [Object]
      , items: [Object]
      , uniqueItems: true
      , default: 'any'
      }
   , properties: 
      { type: 'object'
      , additionalProperties: [Object]
      , default: {}
      }
   , patternProperties: 
      { type: 'object'
      , additionalProperties: [Object]
      , default: {}
      }
   , additionalProperties: { type: [Object], default: {} }
   , items: { type: [Object], items: [Object], default: {} }
   , additionalItems: { type: [Object], default: {} }
   , required: { type: 'boolean', default: false }
   , dependencies: 
      { type: 'object'
      , additionalProperties: [Object]
      , default: {}
      }
   , minimum: { type: 'number' }
   , maximum: { type: 'number' }
   , exclusiveMinimum: { type: 'boolean', default: false }
   , exclusiveMaximum: { type: 'boolean', default: false }
   , minItems: { type: 'integer', minimum: 0, default: 0 }
   , maxItems: { type: 'integer', minimum: 0 }
   , uniqueItems: { type: 'boolean', default: false }
   , pattern: { type: 'string', format: 'regex' }
   , minLength: { type: 'integer', minimum: 0, default: 0 }
   , maxLength: { type: 'integer' }
   , enum: { type: 'array', minItems: 1, uniqueItems: true }
   , default: { type: 'any' }
   , title: { type: 'string' }
   , description: { type: 'string' }
   , format: { type: 'string' }
   , divisibleBy: 
      { type: 'number'
      , minimum: 0
      , exclusiveMinimum: true
      , default: 1
      }
   , disallow: { type: [Object], items: [Object], uniqueItems: true }
   , extends: { type: [Object], items: [Object], default: {} }
   , id: { type: 'string', format: 'uri' }
   , '$ref': { type: 'string', format: 'uri' }
   , '$schema': { type: 'string', format: 'uri' }
   }
, dependencies: 
   { exclusiveMinimum: 'minimum'
   , exclusiveMaximum: 'maximum'
   }
, default: {}
}
DEBUG: 


DEBUG: ----- VALIDATE: -----
DEBUG: result = v.validate(schema);
DEBUG: ----- RESULT 1 ----- 
{ valid: false
, errors: 
   [ { property: ''
     , message: 'Invalid schema/property definition http://json-schema.org/draft-03/schema#'
     }
   ]
}
DEBUG: result = v.validate(schema, schema);
DEBUG: ----- RESULT 2 ----- 
{ valid: false
, errors: 
   [ null
   , { property: ''
     , message: 'Invalid schema/property definition http://json-schema.org/draft-03/schema#'
     }
   ]
}
DEBUG: result = v.validate(schema);
DEBUG: ----- RESULT 3 ----- 
{ valid: true, errors: [] }
DEBUG: result = v.validate(schema, schema);
DEBUG: ----- RESULT 4 ----- 
{ valid: false, errors: [ null ] }

validate will mutate the input object by adding default values for missing defaults. This is unexpected and in the typical case undesired -- the name validate implies a function to check, not modify, the input.

Hi!

Might be missing something, but where exports.coerce() comes from?

TIA,
--Vladimir

validate.js is still using 'optional' defaulting to false, instead of 'required' defaulting to false, inverting the optionality of properties in schemas written against draft-03. Is sent a pull request with a fix.

Given this example in the hyperlink documentation:

{
    "title": "News post",
    ...
    "links": [
        {
            "rel": "comments",
            "href": "/{id}/comments"
        },
        {
            "rel": "search",
            "href": "/{id}/comments",
            "schema": { ... }
        },
        {
            "title": "Post a comment",
            "rel": "create",
            "href": "/{id}/comments",
            "method": "POST",
            "schema": { ... }
        }
    ]
}

I would have expected the links to be an object with the actual rel value as keys, which would look like this:

{
    "title": "News post",
    ...
    "links": {
        "comment": {
            "href": "/{id}/comments"
        },
        "search": {
            "href": "/{id}/comments",
            "schema": { ... }
        },
        "create": {
            "title": "Post a comment",
            "href": "/{id}/comments",
            "method": "POST",
            "schema": { ... }
        }
    }
}

I'd like to see some samples (or examples) for using this library. Generally, projects have this in their README.md

This would prevent people posting issues and pull requests to this repo when it should be to the josn-schema/json-schema repo

https://github.com/json-schema/json-schema

http://json-schema.org/ shows an error:

This page has been temporarily disabled due to a misconfigured custom domain.

It's probably caused by this:
https://github.com/blog/1917-github-pages-legacy-ip-deprecation

The A record for json-schema.org shows:

204.232.175.78

It needs to be updated to:

192.30.252.153
192.30.252.154

https://help.github.com/articles/tips-for-configuring-an-a-record-with-your-dns-provider/

Not sure if this project is still alive, but.

Let's take this simple JSON:

[ { "foo": "bar" } ]

and a schema for it:

{
    "type": "object"
  , "$schema": "http://json-schema.org/draft-03/schema"
  , "id": "http://jsonschema.net"
  , "required": true
  , "properties": {
        "foo": {
            "type": "string"
          , "id": "http://jsonschema.net/foo"
          , "required": true
        }
    }
}

This should be invalid, and it is if you validate your schema with JSV and schema modules. json-schema, though, says that this JSON is valid, probably because of validate.js:93, since typeof [] === 'object'.

sch = {
  type: 'object',
  "properties": {
    "str1": {
      "type": "string",
      "id": "#strref"
    },
    "str2": {
      $ref: '#strref'
    }
  }
};
obj = {
  str1: 'sss',
  str2: 21
};

schema = require('json-schema');
console.dir(schema.validate(obj, sch));

Returns { valid: true, errors: [] }.
But str2 isn't string

Hi!

What's the purpose of such constructions:

if(objTypeDef.hasOwnProperty(i) && !(i.charAt(0) == '_' && i.charAt(1) == '_'))

TIA,
--Vladimir

self-explanatory.

Due to the way in which AMD is tested for in validate.js, this module is incompatible with webpack. When built in a webpack environment, it causes this error:

define cannot be used indirect

I suggest switching to a more standard module test, such as UMD.

Here's a test program:

/*
 * test case for json-schema validation issue with date-time formats
 */

var jsonschema = require('json-schema');
var schema = {
    'type': 'string',
    'format': 'date-time'
};

console.log(jsonschema.validate('asdf', schema));

Here's the output on my system:

dap@sharptooth jst $ uname -a
Darwin sharptooth.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
dap@sharptooth jst $ node -v
v0.10.18
dap@sharptooth jst $ npm ls
/Users/dap/Desktop/jst
└── [email protected]

dap@sharptooth jst $ node issue-datetime.js 
{ valid: true, errors: [] }

"null" is allowed in places where an "object" is required, even one with required properties. Here's a test case:

/*
 * test case for json-schema validation issue with "null" objects.
 */
var assert = require('assert');
var jsonschema = require('json-schema');

var schema, report;

/*
 * BUG: This reports as valid, but I think it should not.  The RFC is not
 * super-clear on this, but it seems to me that 'object' was not intended to
 * include null, since there's a separate null type that's explicitly for
 * creating nullable objects.
 */
schema = { 'type': 'object' };
console.log('attempting to validate "null" as an object');
report = jsonschema.validate(null, schema);
console.log(report);

/*
 * "null" definitely doesn't have the required property "someprop", but this
 * reports as valid, too.
 */
schema = {
    'type': 'object',
    'properties': {
        'someprop': {
        'type': 'object',
        'required': true
    }
    }
};
console.log(
    'attempting to validate "null" as an object with a required property');
report = jsonschema.validate(null, schema);
console.log(report);

/*
 * As expected, an empty object is not valid for this schema.
 */
console.log(
    'attempting to validate "{}" as an object with a required property');
report = jsonschema.validate({}, schema);
console.log(report);

Here's the output on my system:

dap@sharptooth jst $ uname -a
Darwin sharptooth.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
dap@sharptooth jst $ node -v
v0.10.18
dap@sharptooth jst $ node issue-null.js 
attempting to validate "null" as an object
{ valid: true, errors: [] }
attempting to validate "null" as an object with a required property
{ valid: true, errors: [] }
attempting to validate "{}" as an object with a required property
{ valid: false,
  errors: 
   [ { property: 'someprop',
       message: 'is missing and it is required' } ] }

Why the meta-schema for draft-04 does not define the format keyword, but then uses it in the id, $schema and pattern property definitions?

I know, I know, this is _JSON_ Schema after all (though maybe that could be seen in reference to the format of the schema rather than the input!), but to be practical, could not some additional types be spec'd to allow for other JavaScript types like functions, undefined, non-finite numbers, regular expression and Date objects, and DOM objects?

There seems to be a mismatch between the licenses listed in package.json and the files in the lib/ dir. Could you please relicense or add the MIT license to package.json. If you choose to add MIT license could you also add the MIT license text, that is one of the requirements of the MIT license.

I'm packaging this module with Fedora Linux and need to have correct license information to be able to ship this.

Hi!

I have specified the JSON data in my thesis in terms of JSON-schema. What is the recommended/preferred citation strategy?

Thanks!

After doing a

npm install json-schema

then

require('json-schema')

gives me:

Error: Cannot find module 'json-schema'

Taking the sample schema from json-schema.org directly:

var schema = {
    "title": "Example Schema",
    "type": "object",
    "properties": {
        "firstName": {
            "type": "string"
        },
        "lastName": {
            "type": "string"
        },
        "age": {
            "description": "Age in years",
            "type": "integer",
            "minimum": 0
        }
    },
    "required": ["firstName", "lastName"]
};

And calling validate on an invalid object, will result in a return saying its valid:

var js = require('json-schema');
console.log(js.validate({firstName: 'Test'}, schema).errors);

Output is an empty array: []

In places where a "number" is required, a "string" value is accepted. Moreover, numeric constraints like "minimum" are correctly applied to numeric values, but are ignored for string values. Here's a test program:

/*
 * test case for json-schema validation issue with strings as integers
 */
var assert = require('assert');
var jsonschema = require('json-schema');

var schema = {
    'type': 'integer',
    'minimum': 0
};

console.log('validate -1 as a positive integer (expect fail, got fail)');
console.log(jsonschema.validate(-1, schema));

console.log('validate 1 as a positive integer (expect okay, got okay)');
console.log(jsonschema.validate(1, schema));

console.log('FAIL: validate "-1" as a positive integer (expect fail, got okay)');
console.log(jsonschema.validate('-1', schema));

console.log('FAIL: validate "1" as a positive integer (expect fail, got okay)');
console.log(jsonschema.validate('1', schema));

and here's the output for my system:

dap@sharptooth jst $ uname -a
Darwin sharptooth.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
dap@sharptooth jst $ node -v
v0.10.18
dap@sharptooth jst $ npm ls 
/Users/dap/Desktop/jst
└── [email protected]

dap@sharptooth jst $ node issue-int.js 
validate -1 as a positive integer (expect fail, got fail)
{ valid: false,
  errors: [ { property: '', message: 'must have a minimum value of 0' } ] }
validate 1 as a positive integer (expect okay, got okay)
{ valid: true, errors: [] }
FAIL: validate "-1" as a positive integer (expect fail, got okay)
{ valid: true, errors: [] }
FAIL: validate "1" as a positive integer (expect fail, got okay)
{ valid: true, errors: [] }

Hi!

Wouldn't it be better to apply coercion (if defined in the schema and available in exports) only if the value hadn't passed type test, and not unconditionally?

Best regards,
--Vladimir

Hi!
Can you tell me if this is wrong behavior or not?
When I use _validate(obj,schema,{coerce:someFunction}) then I get an (TypeError: Cannot use 'in' operator to search for 'someField' in 1212 at checkObj (.../node_modules/json-schema/lib/validate.js:208:32)).
The schema has:

{
        "type": "object",
        "properties": {
            "code": {
                "type": "string",
                "pattern": "^\\w{6}$"
            }
        }
    }

But in obj instead of 'object' I receive 'string'.
I expect in this situation correct work of validation, but got a broken node.

It seems to me that at line 196 of validate.js we should use else statement as previous route if pass true test. And it is essentially to avoid any checks after errors are taken.

Can you please check my info and take appropriate actions?

Thank you in advance.

Where the code?

a schema containing a property:

thing : { type : "object", "required" : true }

will validate true for:

thing: []
thing: new Date()

This is a bit annoying and plain wrong (though the blame probably lies on JS itself). Perhaps there's some RPC-aligned reason for arrays and dates to be objects?

May I propose you use (or align with) sugarjs (http://sugarjs.com/api) to perform your "is type" validations? It'd be good if the JS community would form some kind of consensus about what is and isn't an object, and I believe sugarjs does a good job of this.

I'll put together a pull request if you wouldn't mind adding an (awesome) dependency.

a security vulnerability is submitted for your repo in huntr
check report https://huntr.dev/bounties/1ae2b7d5-4b3a-4e0a-b275-e793bd57052e

https://www.npmjs.com/package/json-schema shows nearly a million downloads a day, but the last commit was roughly a year ago.

This is also starting to show up as having a security vuln in this, latest version.

Bueller?

Wrong
Sorry

json-schema appears to be a valid node.js module.

tmpmac:lib tmpvar$ pwd
/Users/tmpvar/work/javascript/json-schema/lib
tmpmac:lib tmpvar$ node
> require('./validate');
{ [Function: validate]
  Integer: { type: 'integer' },
  validate: [Circular],
  checkPropertyChange: [Function],
  _validate: [Function],
  mustBeValid: [Function] }
> 

It would be great if I could just npm install json-schema

Hi!

How about reducing error messages to single english words: "type", "missing", "requires", "minimum", ...

This would help i18n, plus chances high that the user of json-schema would want to provide his own text for messages

TIA,
--Vladimir

newest NPM release of this project is 0.2.5, but this git repository has tags only until 0.2.3.

Please tag 0.2.4 and 0.2.5 (and 0.3.0 if/when released...), to aid those wanting to correlate NPM releases with source tracking.

JSON Schema should be possible to self-validate for both

1. meta core schema, and
2. meta hyper-schema

To be exact, its the content of "id" field and "$schema" field, which yields the following error.

[ { property: '',
    message: 'Invalid schema/property definition http://json-schema.org/draft-04/schema#' } ]

I am not sure if the correct logic should ignore these values, any thoughts?

changing https://github.com/kriszyp/json-schema/blob/master/lib/validate.js#L91 to be

!(type == 'integer' && value%1===0 && value !== null)

seems to fix it for me

Great and fast library!

I have and issue with "date-time".

I have my schema as following:

"date": {
"format" : "date-time",
"type" : "string",
"description" : "Event starting time",
"required": true
}

But the library is saying that schema is valid with any string type value. Could you help me to solve this issue?

Hey there!

I belong to an open source security research community, and a member (@Yoshino-s) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

Im on the latest version. Any idea when this will be fixed or some alternatives?

If I have allowAdditionalProperties: false, I always have validation message with empty property name

{
    "property": "",
    "message": "stringThe property categoryName is not defined in the schema and the schema does not allow additional properties"
}

Something is wrong with a "path" in validate.js line 122, I fixed it by

var actualPath = path ? path + "." + i : i;
errors.push({property:actualPath,message:(typeof value) + " property "  ...

and it looks nice after, and also works for nested properties

{
    "property": "categoryName",
    "message": "string property categoryName is not defined in the schema and the schema does not allow additional properties"
}

Not sure if the fix is correct, but could you pls take a look?

There seems to be a small backlog of open issues and a outdated NPM version. Also the draft is updated at https://github.com/json-schema/json-schema

Is it possible to close/merge all those and update the NPM release? Maybe also publish to bower and component.io?

Would you please tag a new release to make b62f1da available for other libraries to use?