ulisesbocchio / jasypt-spring-boot

Jasypt integration for Spring boot
MIT License
2.91k stars 522 forks source link

@EnableEncryptableProperties not working with xml based definitions #58

Closed chupetoide closed 7 years ago

chupetoide commented 7 years ago

I have an application with Spring 4.3.5 with xml based configuration and I have some property sources definitions there.

I'd like to encrypt some property values so I added jasypt-spring-boot (1.15) to my pom.xml and I guess I am in the method 2 scenario (don't use @SpringBootApplication or @EnableAutoConfiguration Auto Configuration annotations). I created a new Java App configuration class with @EnableEncryptableProperties but it only works with @PropertySource java annotations. It doesn't process the xml based definitions. Is that the expected behavior ?

I also tried this suggestion but it didn't work.

ulisesbocchio commented 7 years ago

Can you share the XML config? Or do you have an app in github that I can take a look at? jasypt-spring-boot will pick up all the propertySources present in the environment and nothing else. If you have your XML config using something different it won't work. Seeing the config I might be able to add something to jasypt-spring-boot to support it, or tell you a way it could be done with the current state of the library.

chupetoide commented 7 years ago

Hi Ulises, here is the project: https://github.com/chupetoide/acme/tree/master I put 2 configuration files: one with Xml configuration and the other one with Java.

ulisesbocchio commented 7 years ago

Hey, I took a quick look, it looks like you don't need this:

<context:property-placeholder 
    location="classpath:application-xml.properties" 
    file-encoding="UTF-8" 
/>

If for some reason some of your XML bean definitions don't get properties resolved, try just:

<context:property-placeholder/> 

Without adding any locations to it. The javadoc for PropertySourcesPlaceholderConfigurer says:

Specialization of PlaceholderConfigurerSupport that resolves ${...} placeholders within bean definition property values and @Value annotations against the current Spring Environment and its set of PropertySources.

For you it should be enough with the Environment since that is where jasypt-spring-boot does its thing. The locations passed to property-placeholder are not intercepted by jasypt-spring-boot since it keeps its own local set of PropertySources. To be able to use PropertySourcesPlaceholderConfigurer with locations transparently I would have to add support for it if possible intercepting its own PropertySources. But an Encryptable replacement already exists from jasypt-spring31, it would look something like this:

<encryption:encryptable-property-placeholder
    encryptor="jasyptStringEncryptor"
    location="classpath:application-xml.properties"
    file-encoding="UTF-8"
/>

All in all, I think you should either choose to use jasypt-spring-boot that relies on the environment. Or jasypt-spring31 that relies on PropertySourcesPlaceholderConfigurer. But I wouldn't mix both.

chupetoide commented 7 years ago

Both properties are resolved but the XML-based are not decrypted. We should use Spring XML-based configuration to allow our customers to modify the configuration without re-packaging it.

The jasypt-spring31 approach is not working. It throws an exception at runtime:

Caused by: org.xml.sax.SAXParseException; systemId: http://www.jasypt.org/schema/encryption/jasypt-spring31-encryption-1.xsd; lineNumber: 676; columnNumber: 67; src-resolve: Cannot resolve the name 'context:propertyPlaceholder' to a(n) 'type definition' component.

I added this namespaces and this property configuration:

<encryption:string-encryptor id="myEncryptor" password="password" pool-size="5"/>

<encryption:encryptable-property-placeholder
    encryptor="myEncryptor"
    location="classpath:application-xml.properties"
    file-encoding="UTF-8"
/>

But don't worry. I'll write my own PropertyPlaceholderConfigurer and decrypt there the encrypted values. Please feel free to close the issue. I understand this is not an issue from your library.