feature: class transformer should strip additional properties

[adnan-kamili]

As per the doc, a new instance of class is generated by the class-transformer, then why it contains additional properties. For the following post data:

{
    "email": "adnan11@gmail.com",
    "name": "test name",
    "password": "password4",
    "company": "My Company"
}

And following ViewModel:

export class UserViewModel {

    @MaxLength(256)
    name: string;

    @IsEmail()
    email: string;

    @MinLength(6)
    @MaxLength(72)  // bcrypt input limit
    password: string;

    roles: Array<string>
}

The class instance generated for

    @HttpCode(201)
    @Post()
    create( @Body() user: UserViewModel) {
        console.log(user);
        return { message: "created"} ;
    }

is

UserViewModel {
  email: 'adnan11@gmail.com',
  name: 'test name',
  password: 'password4',
  company: 'My Company' }

Where the expected object was:

UserViewModel {
  email: 'adnan11@gmail.com',
  name: 'test name',
  password: 'password4',
  roles: null }

[NoNameProvided]

Only known properties are checked, others will be left untouched. If you want to exclude one specifically you can use the @Exclude() decorator.

[adnan-kamili]

My concern is how is it an instance of UserViewModel if it doesn't fulfill the contract. User can add in fields like createtAt, updatedAt etc.in the post body which can cause undesired effects.

What we expect is a class instance not what the user provided json parsed object, to ensure safe data is saved into the database. Adding @exclude() decorator for properties which I don't expect is not intuitive, and unnecessarily would require adding all the properties to the view model which I don't want from users/attackers.

[NoNameProvided]

What we expect is a class instance

It is a class instance, all your functions specified in your class will be there.

to ensure safe data is saved into the database

Hmm, so adding @Exclude() won't work when saving the object into the database. It's used to strip properties when serializing them before sending down to client. (via classToPlain function)

Adding @Exclude() decorator for properties which I don't expect is not intuitive

That is both true and false, while it's never bad to explicitly says which properties are forbidden, it is a manual work to add them. This manual work can be easily lowered by extending your class likeexport class UpdateUserPayload extends ForbiddenFields. However again, this wont save you from saving the wrong data in the database.

The solution would be to add a @StictEquals or similar class decorator to allow only the selected fields and throw otherwise, and a @Equals to simply strip down the unknow properties.

@pleerock what do you think?

[adnan-kamili]

All validation libraries like Joi, ajv, validate.js support stripping of properties which are not part of the schema, so this should be supported globally as a flag for class-transformer instead of adding one more decorator to each action. Adding too many decorators in itself also has an overhead for each action when number of actions is very high.

[pleerock]

I didn't quite understood why you are talking about exclude here?

What I understood from this message:

UserViewModel {
  email: 'adnan11@gmail.com',
  name: 'test name',
  password: 'password4',
  company: 'My Company' }
Where the expected object was:

UserViewModel {
  email: 'adnan11@gmail.com',
  name: 'test name',
  password: 'password4',
  roles: null }

Is that he expects roles to be null, but class-transformer makes it undefined. Do you I get it right? If yes, then its expected behaviour and null and undefined are different things and since you don't send in body roles at all you should not have it in transformed object. Or did I understand it wrongly?

[NoNameProvided]

Is that he expects roles to be null, but class-transformer makes it undefined. Do you I get it right?

No, the raised issue is about not removing the company property. It's doesn't exists on the model yet it exits on the transformed object. This is problematic in places like Mongo, when you will end up storing data you didn't want to.

[pleerock]

Thats why people must use typeorm to store documents where you mark each column you want to store a with a column decorator 😃

Okay but seriously its not possible to implement this feature.

In TypeScript its NOT POSSIBLE TO GET KNOWN WHAT PROPERTIES ARE DEFINED IN THE CLASS.
It means we simply don't know if your model has or not "company" property.

[MichalLytek]

Why not? If the property is decorated with class-validator decorator (even @IsOptional()) we can just do:

const reflectedType = Reflect.getMetadata("design:type", UserViewModel.prototype, "company");
if (!reflectedType) {
    delete object["company"];
} else {
    if (object["company"].constructor !== reflectedType) {
        throw new PropertyConveringError();
    }
}

I would like to introduce this type of strictTransform function to class-transformer, which would require decorating each property to collect type but the gain is that we can validate the type of the property and strip additional ones + throw error when some of object properties are invalid (string expected, get boolean instead).

BTW, to get all decorated class property names we can even monkey-patch Reflect.defineMetadata to collect metadata into storage 😆

[pleerock]

If you read comment above author would like to avoid decorating all properties. There is already support in class-transformer to serialize only decoratorated properties (using @Expose decorator).

[MichalLytek]

Serialize yes, but deserialize? The problem is that the received body has additional properties and all that class-transformer do is assign object prototype, not check or strip additional properties, so when you want to store it in db you have to serialize and deserialize again? It makes no sense, it should be done by strictTransform function.