Add configuration to ignore exception when decryption fails?

[vageeshb]

Description:

Using this library on an existing data or document with a newly added Encrypted annotation on an existing field fails because the crypt function (Decoder) throws an exception while loading the data as it expects binary data.

Usecase:

• Application with existing data wants to use this library
• Application with existing non-encrypted document wants to encrypt the fields
• Application with existing partially encrypted document wants to encrypt an existing field

Question:

• Would it logical to allow a configuration option to ignore this exception?

Proposal:

• Allow a configuration option to enable data passthrough on decoding failure
• Handle the exception thrown by the Decoder Function and pass the data as-is if the non-binary

[agoston]

That is an excellent point!
It already came up that sometimes, you have to do data migrations because of changes in @Encrypted annotations.

For now, the recommended practice is similar to what you would do for data migrations with spring-data-mongodb:

• make a new collection. make a one-off script that reads all from the old version and writes it in new version. this can be done online, while your service is running, but during that time, you'll have to read both collections.
• make a new @document, backed by the same collection. Make a one-off script that reads, e.g. via MongoTemplate, into the old format, and if that does not fail, convert in java into the new format and save it back.
• if you feel really advanced, you could make a version field in your document and hook into the spring-data-mongodb event handlers like this library does, to call the proper type mapper as per the version field in the Document.

These ideas aside, it is indeed possible to add a config option for allowing non-binary data simply pass through in the Decoder. I would be most delighted if you could submit a pull request for that; if not, I can make this soon-ish.

[agoston]

Fixed in release 2.1.0.