Key_id now part of the encrypted binary to make full use of Ecto.Type behaviour

[dovadi]

I implemented the idea of @moritzploss as he suggested in #33

This solved several issues:

• double (implicit and explicit) encryption and decryption is unnecessary
• now we make full use of the Ecto.Type behaviour and we are able to remove the complicated prepare_fields/1 function
• In the previous implementation key rotation would simple not work. After adding a new key the initial decryption through the load function (as defined as Ecto.Type behaviour) of an already encrypted field would always be done with the latest encryption key, which would cause an error because it was encrypted with the second last encryption key.
• The original prepare_fields/1 function could not handle parameters with keys as string because of extra merging of the attrs, which is a common practice done in controllers.

[codecov]

Codecov Report

Merging #34 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #34   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines           64        36   -28     
=========================================
- Hits            64        36   -28     

Impacted Files	Coverage Δ
lib/encryption/aes.ex	100.00% <100.00%> (ø)
lib/encryption/encrypted_field.ex	100.00% <100.00%> (ø)
lib/encryption/user.ex	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c89ea7...ceec148. Read the comment docs.

[moritzploss]

Hi @dovadi, great that you implemented the changes! I think this is a much needed improvement. My only concern is that these changes would also need to be reflected in the README. Looking at the issue a couple of weeks ago, I felt that changing the README is a much bigger task than changing the code since it basically requires a complete re-write. But without updating the README it's probably quite confusing. What do others think?

[nelsonic]

I agree that it's great that @dovadi has made the time to update the code in this tutorial to reflect the suggestion. Ideally the README.md instructions would match the code to avoid confusing people who are following the instructions in the README.md.
But given how much effort/time it will take to update the README.md I would not expect anyone to do it. Also, I would sooner completely re-write the README.md to use Fields rather than instructing people to hand-code Ecto Types.

So with that in mind I'm going to approve/merge the PR and if anyone in the community wants to do "Part Two" of this task (Updating the README.md to match the code) the PR will be very welcome.

[nelsonic]

@dovadi thanks very much for making the time to make these updates/simplifications to the code. 🎉

[dovadi]

Ah I was so focused on the code itself that I totally overlooked the readme.

I feel my job is not finished yet, I will have a go at it. Expect a new PR the coming days ......