Strict Schema Validation for JaySchema - node.js

I'm playing around with JaySchema (https://github.com/natesilva/jayschema) for a NodeJS application I'm building using ExpressJS. I was wondering if anyone has created, or knows how to, create custom code that ammends the library to allow "strict" validation... By "strict", I mean that any JSON properties that aren't within the schema itself return an error state for the schema's validation.
If anyone has any insight into this, I'd love to hear from you.
Also, if anyone knows an alternative library (preferably available using NPM) that does offer this option, please let me know.
Thanks!

So after a bit of digging, I figured out the solution.
JaySchema supports JSON Schema's standards (details on JSON Schema Standards Docs found here). Within those standards an "additionalProperties" keyword is defined as exactly what I was looking for (more information found here).
According to the documentation (specifically section 5.4.4.4, and an example in 5.4.4.5), if "additionalProperties" is set to the boolean false, then if properties beyond those defined in the schema are found, validation fails.
Since, as I mentioned above, JaySchema supports this JSON Schema standard, if you add "additionalProperties" at the object level to false, you'll achieve the "strict" validation I was looking for.
If you're interested, you can check out the test I have up on GitHub below:
schema: with "additionalProperty" set to false
test: with an additional property added to cause validation failure

Related

rapidjson: is it possible to use the Schema tools to generate / output schema?

Ok, what im hoping is possible here is that given an input document with some json in it, I was considering creating a schema document using this json and then output it to a string which I can then use as a reference for future validation. (we have a LOT of json passed around in our software, so creating a schema from what we have will allow me to catch in CI when changes have been made so we can review for privacy violations).
I realise this isn't at all what the schema validator tools are for. but it looks like they do create internally the schema, does anyone have any idea how I might be able to do this?
Thanks

Best way to implement ACL with Mongoose

I have my data model already defined and implemented. I can very easily write manually the filter to filter out non-authorized results for the user who sent the query (which would be in the style of: "collection.acl.personId": queryPersonId )
My problem is, where and how should I write this "thing" to be as automatic as possible?
I tried to do it with a custom query and a static method, but did not had any luck on both.
Static method con: I don't want to rewrite all my code to use .then(). I want to keep the current chaining.
Custom query: it simply did not worked, even by following the doc.
Ideal the result would be something like
Model.findWithAcl(filters).lean()
Model.findOneWithAcl(filters).lean()
Note that we are using Typescript. The priority would be to have something working, but having the ability to have a working type would be the second priority right after.
Thanks for any help
Casl mongoose gives a very good way of filtering both results (row level) and fields from collections. Note that it also can be used in the front end.
Great package that works very well with auth0 rights.
https://casl.js.org/v5/en/guide/intro
https://casl.js.org/v5/en/package/casl-mongoose

express-validator used in MDN express tutorial

The Express MDN tutorial here uses the following code to do a validation step
// Validate that the name field is not empty.
body('name', 'Genre name required').isLength({ min: 1 }).trim(),
What I don't get is why trim() is chained after the isLength() validation. Shouldn't it be the other way around, or is it the same semantics either way?
I did try looking around in the express-validator doc for a mention of something like this, but was unsuccessful.
UPDATE
In response to gustavohenke's answer, I think what was confusing me, was that I was seeing two sanitization points as shown in the MDN express tutorial screenshot below:
so when I read the validation doc for express-validator "If you use any of the sanitizers together with validators, the validated value is the sanitized one", I was wondering which sanitization point?
From what I've characterized, however, is that the documentation in the express tutorial (that says sanitizers in the validation step only apply to that validation step and don't mutate the request, and so another sanitizer is needed) is not true anymore. In other words, I think you can do all sanitization and validation in one chain.
To get it clear first: trim is a sanitizer, not a validator, like isLength.
Currently (as of v5.x.x), when you specify both sanitizers and validators in the same chain, sanitizers will always run before validators. If you specify more sanitizers, they will run in the order specified.
It's documented behaviour, but it's quite easy to not see it:
If you use any of the sanitizers together with validators, the validated value is the sanitized one.
This is a point of astonishment for users, as you might have guessed, and it's planned to change on an upcoming major version.

Update all attributes in entity(core data) to true with swift

Hopefully I can make it clear what I'm attempting to accomplish, so here goes.
I'm using Core Data to store my data. And many of my view controllers I have a tutorial that will pop up to explain how to use my app. I've created an entity called "tutorials" where each attribute is a boolean storing if the tutorial for that view controller will be shown.
When the app is run for the first time it creates an entry in the tutorials entity and then sets all the attributes in it to true. Currently I'm setting each attribute by using something like this tutorials.attributeName = true, but since I know all of the attributes will be true, I was hoping to use something similar to this question.
Core Data - Iterating through the attributes of a NSManagedObject
I tried using this from the answer that shows Swift 3.0, but it turns out I can't use item.valueForKey(key) = true since item.valueForKey(key) is read only. Since I already have tutorial set as my tutorial entity, my code is much more simple. But I need to know how to set the attribute value when using the key.
for key in tutorials.entity.attributesByName.keys {
//Code to set attribute key to true
}
Any help to get me that last mile would be much appreciated.
Thank you
All right, I was able to figure it out, I should be using this code to do what I want.
tutorials.setValue(true, forKey: key)

Loopback - Easiest way to extend a built-in model

I've been using Loopback to create an API. The documentation is generally really good but doesn't really answer my question about the following: how do I extend (not replace) a built in model?
The most promising piece of information came from this page - it specifies the way of basing a class from another class, via inheritance. This is useful but not ideal - I'd like to create relationships to custom models from the stock models, for example - "Role" should have many "Permission".
The page I mention also shows a Javascript file, located at common/models/<modelName>.js, where it states you can "extend" a model based on the properties and options you give it. The server never seems to hit the file... For example - I put a file in common/models/role.js with the following content:
var properties = {
exampleProperty: {type: String, required: true}
};
var user = loopback.Model.extend('Role', properties);
console.log('test');
First off, it doesn't seem to hit the file at all (no console.log output given). Second, obviously because of the first point, it doesn't extend the model with the properties I created.
Am I missing something obvious or is the documentation just plain wrong?
You should generate a new model via slc loopback:model named user. By default, the built in user is named User, which is why you can use lowercase user or even UserModel if you prefer. Then when you are prompted by the model generator for a base model, choose User. See https://github.com/strongloop/loopback-faq-user-management/blob/master/common/models/user.json#L3

Resources