Use embedded entities to define instead of a decorator

[generalpiston]

typeorm has embedded entities (http://typeorm.io/#/embedded-entities) which allows for custom type definitions. If listeners can operate on embedded entities, this would negate the need for decorators and complicated field search code.

Example defintion:

import { Column, AfterLoad, BeforeInsert, BeforeUpdate } from "typeorm";

import { encryptData, decryptData } from "../transformers";
import { IEncryptedEntityOptions } from "./IEncryptedEntityOptions";

export class EncryptedEntity {
  options: IEncryptedEntityOptions;

  @Column({
    type: "varchar",
    nullable: false
  })
  data: string;

  EncryptedEntity(options: IEncryptedEntityOptions) {
    this.options = options;
  }

  @AfterLoad()
  decryptFields(): void {
    if (this.options.autoencrypt) {
      this.data = decryptData(this.data);
    }
  }

  @BeforeInsert()
  encryptFieldsBeforeInsert(): void {
    if (this.options.autoencrypt) {
      this.data = encryptData(this.data);
    }
  }

  @BeforeUpdate()
  encryptFieldsBeforeUpdate(): Promise<this> {
    if (this.options.autoencrypt) {
      this.data = encryptData(this.data);
    }
  }
}

[generalpiston]

It looks like embedded entities do not support listeners. They seem to make more sense with groups of fields rather than adding encapsulated functionality.

[generalpiston]

According to @pleerock:

support for listeners in embeds will be added in 0.1.6

[pleerock]

yeah I already implemented it, will publish new version today or tomorrow.

[pleerock]

btw few thoughts regarding this library design:

@Entity()
export class User extends EncryptedBaseEntity {
  ...
  @EncryptedColumn({
    key: "d85117047fd06d3afa79b6e44ee3a52eb426fc24c3a2e3667732e8da0342b4da",
    algorithm: "aes-256-cbc",
    ivLength: 16
  })
  @Column({
    type: "varchar",
    nullable: false
  })
  secret: string;
  ...
}

• I would suggest you to avoid forcing users to extend EncryptedBaseEntity class if possible. Usually users don't like to extend third party classes or change their model inheritance tree. (just imagine if there is another libs who force to extend their entities too and user uses them all)

• even @EncryptedColumn looks fine, its not a valid from typeorm point of view because this decorator is not creating a new column (like all Column decorators in typeorm), it just makes it encrypted. I would name it simply @Encrypted instead.

Also, its no a suggestion, just a hint most users don't know. You can override ColumnOptions properties and do it alternatively this way (it will be type-safe):

  @Column({
    type: "varchar",
    nullable: false,
    encrypt: {
        key: "d85117047fd06d3afa79b6e44ee3a52eb426fc24c3a2e3667732e8da0342b4da",
        algorithm: "aes-256-cbc",
        ivLength: 16
    }
  })

[pleerock]

its just my few cents, keep doing good job, I remember I had project needed such encryption feature a long time ago, we made an ugly solution, wish we had typeorm and this library those days.

[generalpiston]

Awesome! Thanks for the feedback @pleerock and getting 0.1.6 in so quickly!

[pleerock]

I was talking about a bit different design where users will not need to import anything from "typeorm-encrypted at all". Read here. Having to put ExtendedColumnOptions into @Column is not a good option for user imo.

[generalpiston]

@pleerock makes perfect sense. Will follow up at #11.

[generalpiston]

Less necessary with Transformers in #14 .