Closed garbados closed 2 years ago
One solution would be to store exportString
in a local document in the encrypted database instead, so that it is only ever lost if the encrypted database is lost as well. This would be a breaking change, but that's why we're in beta.
Given code like the following, running in a web page:
This will work the first time, but subsequent runs will encounter a
"Could not decrypt!"
error. This is because ComDB stores anexportString
in a local document in the decrypted database, which it uses along with the given password to decrypt the encrypted database. Because the in-memory database is wiped each time the program ends, thisexportString
value is also wiped, essentially orphaning all your encrypted data. This means ComDB does not currently work with an in-memory adapter, pending architectural changes.