Update README for external secret

[Destreyf]

I just started using this library, and am happy to say that it's working great for me.

I do not believe that there needs to be any special treatment for a file based config and I've outlined my approach below using the library as is (in NPM).

Create a typescript file that exports the config for the EncryptionTransformer and just use it directly, so in my case i have the following:

encryption-transformer-config.ts

import { environment } from '@server/environment'; // This is a config file that's swapped out based on environment and it uses ENV variables to define certain properties.

export const MyEncryptionTransformerConfig = {
  key: environment.secret,
  algorithm: 'aes-256-cbc',
  ivLength: 16
};

And i use it by importing into my entity

MyEntity.ts

... // Other imports for entity stuff here.
import { MyEncryptionTransformerConfig } from '@server/encryption-transformer-config';
import { EncryptionTransformer } from 'typeorm-encrypted/lib/transformer'; // My IDE (Webstorm) complained when using 'typeorm-encrypted'

export class MyEntityWithEnc extends BaseEntity {
  ...
  @Column({
    type: 'text',
    transformer: new EncryptionTransformer(MyEncryptionTransformerConfig)
  })
  secretField1: string;
}

This allows me to use a unified configuration based on secrets that i'm already using in other places within my application and I can quickly change out config values across the platform for testing.

You could also easily add overrides per entity, imagine i added a second property to the above entity.

... // imports and what-not from above
export class MyEntityWithEnc extends BaseEntity {
  ...
  @Column({
    type: 'text',
    transformer: new EncryptionTransformer({...MyEncryptionTransformerConfig, ivLength: 32})
  })
  secretField2: string;

The power of the spread operator allows a ton of flexibility when dealing with these use cases.

[generalpiston]

@Destreyf awesome! I think it makes sense to add this to the README as a guideline on how to handle secrets for this library.

[moltar]

I agree that file based config seems unnecessary and outside the scope of the library IMO.

Also it guides library consumers to wrong security decisions. I don't think you should be storing encryption keys in files anyways.

[generalpiston]

@moltar and @Destreyf let's adjust this issue to be a README update based on guidance from @Destreyf

[Destreyf]

@generalpiston This can be closed.