Hi guys,
I have a mix of proposal question on our cipher service:
1. why do we have impl details in the api? salt and setter are impl details
no? Also it sounds like a transversal concern of the ciphering by itself so
why not removing it from the API (or deprecating it)
So proposal is to move
public interface CipherService
{
void setMasterHash(String masterPassword, String masterSalt,
boolean overwrite) throws IOException;
String encrypt(String cleartext, String masterSalt);
String decrypt(String encryptedValue, String masterSalt);
}
to
public interface CipherService
{
String encrypt(String cleartext);
String decrypt(String encryptedValue);
}
2. Why isnt it linked to our config? Here is what I'd like (syntax can be
discussed but just want to share the idea/usage):
my.super.config = cipher:thisIsCiphered # default impl
my.super.config = cipher:customCipherServiceAlias:thisIsCiphered # to
support to aggregate configs using different ciphering on the backend
but if i read "my.super.config" I get "this is a super value" for instance.
Technically we can add a default filter probably and support it OOTB pretty
easily, it also enable to support it in the logging automatically to skip
it since ciphered data are by default sensitive data.
Since next release will be 1.9 I think we can clean it up now before it
gets out.
Wdyt?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
