[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198179#comment-14198179
 ] 

ASF subversion and git services commented on CLOUDSTACK-7242:
-------------------------------------------------------------

Commit c3e5964dcbbd3b3ff34562aeeb9f8daa154ee7d1 in cloudstack's branch 
refs/heads/master from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3e5964 ]

Fixed CLOUDSTACK-7242: Adding a securing config using configDepo doesnt work

In ConfigurationVo, changed the setter to do the encryption if required
like the getter. Called the setter in constructor as well.

Removed references of encryption check in different places.

Reviewed-by: Santhosh Edukulla

This closes #35


> adding a Secure config using the new ConfigDepot and ConfigKey breaks the 
> build when encryption is enabled
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7242
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7242
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Management Server
>            Reporter: Rajani Karuturi
>            Assignee: Rajani Karuturi
>            Priority: Critical
>             Fix For: 4.5.0
>
>
> In the inner layers, when it get the value of the key it tries to do decrypt 
> if its a secure or hidden field. But, it doesn’t encrypt while adding the 
> config.
> Here is code snippet from ConfigurationVO
> {noformat}
>    @Override
>     public String getValue() {
>         return (("Hidden".equals(getCategory()) || 
> "Secure".equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
>     }
>     public void setValue(String value) {
>         this.value = value;
>     }
> {noformat}
> we should make the getter and setter consistent. Otherwise, you won’t be able 
> to introduce any new secure/hidden configs unless you put the encrypted value 
> in the db before. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to