-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: unintented encryptions/decryptions with a lock context #58
Conversation
I'd prefer if we could use a stronger type guarantee of the use of LockContext. I've created an example of what I mean here. The idea is that when you call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to see this use the type state pattern like here: https://gist.github.com/coderdan/d6e620609b46b760471f5c9b65c2f47a
Enforced lock context to be called as a proto function rather than an optional argument for crypto functions.
There was a bug that caused the lock context to be interpreted as undefined when the users intention was to use it causing the encryption/decryption to fail.
This is a breaking change for users who were using the lock context as an optional argument, hence the major version bump.
To use the lock context, call the
withLockContext
method on the encrypt, decrypt, and bulk encrypt/decrypt functions, passing the lock context as a parameter rather than as an optional argument.Old:
New: