Nest: Strip/reject unexpect properties in Validation pipes or class-validator?

Created on 20 Dec 2017  路  12Comments  路  Source: nestjs/nest

I'm submitting a...


[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior


When submitting unexpected properties in the body of an HTTP request (POST/PUT endpoints), the validation pipe (using class-transformer and class-validator) allows it without sending any warning or allowing us to forbid this behavior.
I assume this is linked to https://github.com/typestack/class-validator/pull/118

Expected behavior

When submitting {"name": "Fluffy Cat", "age": 15, "paws": 3} whereas the DTO is {name: string, age: number}, the property paws should be stripped or raise (in some way) a validation error.

What is the motivation / use case for changing the behavior?


Allowing developers to reject payloads with unexpected properties, just like Joi or AJV. This is especially dangerous for MongoDB users, who might store the provided input "as is".

Environment


Nest version: 4.5.1

For Tooling issues:
- Node version: 8.9+  
- Platform:  Linux 


Most helpful comment

@pb-expa i'm using whitelisting and it serves me well.
Finally it comes to:
@UsePipes(new ValidationPipe({transform: true, whitelist: true}))
and all unlisted options will be stripped.

All 12 comments

Hi @VinceOPS,
Yeah, we need to wait for class-validator update.

Hi @kamilmysliwiec

I tried a few things inside the code of class-validator & class-transformer and it looks like getting a list of the "expected fields" (to exclude the unexpected ones) is not that simple. I would have loved to be able to generate a very simple AJV (or Joi) schema, in order to (only) specify a list of "required" fields. Indeed, I think the PR I linked in the issue (PR 118) is not really convenient, as it requires using extra decorators.

Any idea regarding my wish to "convert" the DTO/interface into an AJV/Joi schema? (I know we cannot read the list of properties of a TS interface, though :/ ).

You have to create your own pipe, unfortunately.

Hmm.. Actually, I figured out that it should not be really difficult. You just need to create a Pipe which would reflect properties from metatype and then pick them inside this pipe. 馃檪

This sounds like a pure TypeScript approach, I like it 馃憤 . Will give it a try. Thanks!

Let's share the results then! 馃檪

Hi @kamilmysliwiec
I'm not sure about how to reflect metatype properties if I did not emit any metadata (myself) on each property, though.

Let's say I have a CreateCatDto like this one (my metatype):

export class CreateCatDto {
  @IsString()
  readonly name: string;
}

I have no way to expose its properties without using a decorator on each, right? Or I might use a default value for all properties and use something like Object.getOwnPropertyNames(new metatype()) but it looks worth than a decorator. What do you think? Thanks

@VinceOPS yep, the decorator is obligatory, but since you're using class-validator at once, you can reuse its metadata. This solution sounds better than default values.

@VinceOPS interested to hear what you ended up doing with this?

@pb-expa i'm using whitelisting and it serves me well.
Finally it comes to:
@UsePipes(new ValidationPipe({transform: true, whitelist: true}))
and all unlisted options will be stripped.

@pb-expa Sorry I never got a notification for your message :disappointed:. However I got one from @peterpro. I'm doing the same thing: using whitelist from class-validator directly in the built-in Nest ValidationPipe.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings