Summary

On validation error make the path to the problematic field available to the client. Currently the path is only a field in ValidationError but later it can be used to improve the error messages (related to #100, #144)

Example

Schema

{
   "type":"object",
   "properties":{
      "foo":{
         "type":"object",
         "properties":{
            "bar":{
               "type":"integer"
            }
         }
      }
   }
}

Input

{
  "foo": {
    "bar": "some string"
  }
}

Produced Error

path: [foo, bar]

It seems like the presence of "patternProperties" interferes with validation that should happen in "properties".

This replit shows an example of an instance that should fail validation (and does fail in jsonschemavalidator.net). If you comment out the "patternProperties" portion of the schema, it fails as expected.

I don't have a good enough understanding of the jsonschema internals, but it seems like this could be related to changes from #173 .

UPDATE: I updated the replit and the jsonschemavalidator link to provide a more minimal example.

At the moment, jsonschema supports the format keyword for formats defined in Drafts 4, 6, 7. However, JSON Schema allows custom values for the format keyword.

It will be awesome to provide a way for the end-user to validate their own formats.

As all validators are "compiled" to some structs (to avoid some run-time overhead e.g., map lookup, etc.), I think that the public API might look like this:

use jsonschema;
use std::collections::HashMap;
use serde_json::{json, Value};

struct CustomFormatValidator {}

// New trait somehow derived from `Validate`?
impl jsonschema::SomeNewTrait for CustomFormatValidator {
    fn is_valid(&self, _: &jsonschema::JSONSchema, instance: &Value) -> bool {
        if let Value::String(item) = instance {
            item == "bar"  // Format matching logic goes here
        } else {
            true
        }
    }
}

fn main() -> Result<(), jsonschema::CompilationError> {
    let schema = json!({"format": "custom"});
    let instance = json!("foo");
    let mut formats = HashMap::new();
    formats.insert(
        "custom": CustomFormatValidator
    );
    // Shortcuts
    jsonschema::is_valid(&schema, &instance, Some(formats))
    // Compiled schema
    let compiled = jsonschema::JSONSchema::options()
        .formats(formats)
        .compile(&schema)
        .expect("Invalid schema");
    compiled.is_valid(&instance)
}

It will be nice to avoid the boilerplate that extracts the actual string from Value::String, so the user won't write this code for each format.

Anticipated changes to implement this:

• Take extra argument for the formats map in jsonschema::is_valid;
• Extend CompilationOptions builder to handle formats;
• Store the formats map as a part of CompilationContext;
• Inside format.rs take a look at this mapping before going to take a look at the built-in validators;
• Make the Validate trait public and implement some trait on top of it to avoid boilerplate?

For now, I think it is OK to keep the scope on the Rust code only. A similar feature for bindings could be implemented later.

Hi,

Sorry, I've been trying to work this out myself, but I'm not sure what's going wrong.

Validation error: failed to resolve https://schema.rawkode.dev/organization: error sending request for url (https://schema.rawkode.dev/organization): error trying to connect: invalid URL, scheme is not http
Instance path:
Validation error: failed to resolve https://schema.rawkode.dev/person: error sending request for url (https://schema.rawkode.dev/person): error trying to connect: invalid URL, scheme is not http
Instance path:

These URLs are definitely OK and I'm not sure what I've done wrong.

I've tried using http instead of https in my schema, but the problem is the same.

Any help appreciated.

In the current form it is impossible to retain a non-static reference to JSONSchema until the end of the program's execution. The below block demonstrates the problem.

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    let schema_file = fs::File::open("config/schema.json").unwrap();

    let schema: Value = serde_json::from_reader(schema_file).unwrap();
    let validator = JSONSchema::compile(&schema, None).unwrap();

    let ad = AppData{
        validator: Arc::new(validator)
    };

    HttpServer::new(move ||{
        App::new()
            .data(ad.clone())
            .service(echo)
    })
    .bind("localhost:9070")?
    .run()
    .await
}

#[derive(Clone)]
pub struct AppData<'a> {
    pub validator: Arc<JSONSchema<'a>>
}

The above code results in the below compiler error:

error[E0597]: `schema` does not live long enough
  --> src/main.rs:15:41
   |
15 |     let validator = JSONSchema::compile(&schema, None).unwrap();
   |                     --------------------^^^^^^^-------
   |                     |                   |
   |                     |                   borrowed value does not live long enough
   |                     argument requires that `schema` is borrowed for `'static`
...
31 | }
   | - `schema` dropped here while still borrowed

One(or the only?) way to get this fixed is to let JSONSchema own the Value containing schema.

We use tuples for geographic coordinates and bounding boxes which doesn't seem to have a direct mapping in JSON Schema.

This pull requests converts the tuple into a list to fix ValueError: Unsupported type: 'tuple' when validating a object that contains a tuple.

{ "bbox": (1,2,3,4) }

Uses fancy-regex in place of regex for matching against all patterns in JSON schemas.

regex is still used when converting a RegEx for ECMA 262 to take advantage of the Regex::replace_all method, which is not included in fancy-regex. Since fancy-regex depends on regex anyway, this does not affect the final size of the compiled binary (thanks to this commit for the idea).

I also removed the test from #214, since that pattern is supported in this PR.

When a validation error is reported, it contains only instance_path that points to the erroneous part of the input, but there is no information about what part of the schema caused this error.

The gist of the implementation is to keep a stack of strings while the input schema is compiled. The stack should be convertible to paths::JSONPointer.

The process for regular, non-composite validators (more on this below):

• When the compilation process enters a validator, push its relevant keyword name to the stack (e.g. properties);
• When the validator struct is created, clone this stack and store it within this struct;
• When the validator is compiled - pop from the stack

I think that pushing/popping could be implemented similarly to instance_path - a linked list without heap allocations. This way, the actual popping step is not needed at all.

Composite validators are slightly more complicated - they are single structs that implement the logic for multiple different keywords or their specific variants (e.g. this one handles patternProperties and additionalProperties: false) which is done due to performance reasons.

To handle them, the stack should not be pushed during compilation, but rather during validation - if a validation error happens, the stored stack should be cloned, and the exact keyword variant should be pushed to it. And finally, it is moved to ValidationError.

Validators live in keywords.

A lot of work in this direction was done by @gavadinov in https://github.com/gavadinov/jsonschema-rs/commit/40149322bfdf5549a0150122a00fa66dfe770828, and I think that it could be a great base for implementing this feature.

@gavadinov, let me know if you are OK if somebody can base their work on your commit, or if you want to continue it yourself :)

Hi there, bump into here via hacktoberfest mark.

Honestly most likely it doesn't address JSONPointer correctly in errors. And I was not sure which type of error better use for things like as64 error or regex syntax error but I did used ValidationError::format.

Note: there might be an issue with cargo fmt.

closes #235

Thank you for the library.

Validating 3.0 against {"exclusiveMaximum": 3.0} will give 3.0 is greater than or equal to the maximum of 3. But the last number in the error message should be 3.0. It affects exclusiveMaximum, exclusiveMinimum, minimum, maximum.

E.g. in AdditionalPropertiesNotEmptyValidator. Because during the validation we use self.properties.contains_key(*property) which will be O(logN) (because of BTreeMap). We can use HashMap to have O(1).

As perf showed, significant time is spent on it

I'm not very familiar with ahash, or WASM in general, but it seems like ahash's default randomness source panics when run inside a WASM environment. This change should make it so that jsonschema uses the runtime randomness source by default, but will not require it when included with default-features = false.

Hi, First of all, I'm not the maintainer of tauri.

I find the tauri-cli crate used jsonschema, and I am trying run it with wasm , When I run here, an error is reported.

so, I changed it like this, Because tauri does not use this part when parsing json. From the perspective of jsonschema, this change should be inappropriate. Is there a more reasonable solution ?

The logic for multipleOf compares the remainder of a division with the f64 EPSILON constant to decide if a number is a multiple or not. This approach doesn't make sense. EPSILON is simply the difference between 1.0 and the next larger representable number. With regards to the multipleOf calculation this is just an arbitrary constant and comparing remainders to it gives us no guarantees.

EG:

1e-15 is a multiple of 1e-16. But (1e-15 / 1e-16) % 1.0 = 1.7763568394002505e-15 which is greater than epsilon so it is incorrectly said to not be a multiple.

1.3e-16 is not a multiple of 1.3. But (1.3e-16 / 1.3) % 1.0 = 9.999999999999999e-17 which is less than epsilon so it is incorrectly said to be a multiple.

Add support for user defined custom keyword validation. The user provides and registers custom validator functions when configuring a JSONSchema.

Custom keyword validators may be used when the user wants to enforce constraints that can't, or can't easily, be expressed in JSON schema.

This PR addresses at least some of the features requested in #379 by @tamasfe as well as my own. The same pros and cons described in #379 apply. The PR also follows the structure of #354, but of course uses validation functions as opposed to sub-schema for validation.

We could collapse the two user implementable validation functions into a single trait, mirroring the internal Validate trait. Implementations would have to sit behind an Arc.

Example usage

use jsonschema::{CustomKeywordDefinition, ErrorIterator, JSONSchema, paths::JSONPointer};
use serde_json::{json, Value};
use std::sync::Arc;

fn validate(
    instance: &Value,
    instance_path: JSONPointer,
    schema: Arc<Value>,
    schema_path: JSONPointer,
) -> ErrorIterator {
    // ... validate instance ... 
    Box::new(None.into_iter())
}
fn is_valid(instance: &Value, schema: &Value) -> bool {
    // ... determine if instance is valid ... 
    return true;
}
let definition = CustomKeywordDefinition::Validator { validate, is_valid };
assert!(JSONSchema::options()
    .with_custom_keyword("my-type", definition)
    .compile(&json!({ "my-type": "my-schema"}))
    .expect("A valid schema")
    .is_valid(&json!({ "a": "b"})));

I'm using an async S3 client to load schemas from a bucket. I've hit a wall in that SchemaResolver is not async, but I need to call an async method within it. Is AsyncSchemaResolver on the roadmap or is there a known work around?

///
/// Download an object from the S3 bucket and turn the result as Bytes
/// 
pub async fn download_object(client: &Client, bucket_name: &str, key: &str) -> Result<Bytes, S3Error> {
    let resp = client
        .get_object()
        .bucket(bucket_name)
        .key(key)
        .send()
        .await?;
    let data = match resp.body.collect().await {
        Ok(data) => data,
        Err(e) => return Err(S3Error::GetObjectError{ bucket_name: bucket_name.to_string(), key: key.to_string(), msg: e.to_string() }),
    };
    let data = data.into_bytes();

    Ok(data)
}

///
/// Download and object from the S3 bucket and return the results as a json Value
/// 
pub async fn download_json(client: &Client, bucket_name: &str, path: &str) -> Result<serde_json::Value, JsonError> {
    let data = download_object(client, bucket_name, path).await?;
    let json: serde_json::Value = serde_json::from_slice(&data)?;
    Ok(json)
}

struct S3SchemaResolver {
    client: Client,         // S3 client
    bucket_name: String     // name of bucket that holds schemas
}

impl SchemaResolver for S3SchemaResolver {
    fn resolve(&self, root_schema: &Value, url: &Url, original_reference: &str) -> Result<Arc<Value>, SchemaResolverError> {
        //
        // add the base path to the reference
        //
        match download_json(&self.client, &self.bucket_name, original_reference).await {
            Ok(schema_value) => Ok(Arc::new(schema_value)),
            Err(json_error) => {
                let msg = format!("{}", json_error);
                log::error!("{}", msg);
                Err(anyhow::anyhow!(msg))
            }
        }
    }
}