To manage migration with Liquibase, I am using a properties file that holds all the information about the database connection. The pitfall of this file is that it discloses my database password since it is a plain text file. Is there a way to avoid that ? Does Liquibase support any kind of encryption for the properties file ?
Have a look on this jira: https://liquibase.jira.com/browse/CORE-1932
Looks like you may use your own property provider class to handle encryption etc. I haven't seen any docs for it, but you can browse commits for this task.
Related
I have a service running on my linux machine that reads data stored in a .json file when the machine is booting. The service then validates the incoming JSON data and modifies specific system configurations according to the data. The service is written in C++ and for the validation im using https://github.com/pboettch/json-schema-validator.
In development it was easy to modify the JSON schema and just adapt the data manually. I've started to use semantic versioning for my JSON schema and included it the following way:
JSON schema:
{
"$id": "https://my-company.org/schemas/config/0.1.0/config.schema.json",
"$schema": "http://json-schema.org/draft-07/schema#",
// Start of Schema definition
}
JSON data:
{
"$schema": "https://my-comapny.org/schemas/config/0.1.0/config.schema.json",
// Rest of JSON data
}
With the addition of the version, I am able to check if a version mismatch exists before validating.
What I am looking for is a way to automatically migrate the JSON data to match the newer schema version, if a version mismatch is identified. Is there any way to automatically achieve this, or is the only way to manually edit the JSON data to match the schema?
Since I plan on releasing this as open source I would really like to include some form of automatic migration so I can just ask the user if he wants to migrate to conform to the newest schema version instead of throwing an error, if a version mismatch was identified.
What you're asking for is something which will need to make assumptions to work.
This is an age old problem and similar for databases. You can have schema migrations generated with many simple changes, but this is not viable if you wish to translate existing data automatically too.
Let's look at a basic example. You rename a field.
How would a tool know you've renamed a field vs removed an old one and added a new one? It essentially, cannot.
So, you need to write your migrations by hand.
You could use JSON transformation tools like jq or fx to create migration scripts without writing it in code, which may or may not be preferable. (jq has a steeper learning curve but it's also very powerful.)
Every time I write query using the bq CLI tool I have to specify --use_legacy_sql=flase. I need to configure this. Google's documentation on this states it must be edited in the file $HOME/.bigqueryrc but there is no such file. In fact I couldn't find the .bigqueryrc named file anywhere on the server. Please help me to save few seconds every time I write a query. Thanks.
Following comments conversation above - the file under discussion - .bigqueryrc - can be created (manually) and populated with "default" flag values as described at the Setting default values for command-line flags BigQuery documentation.
I am using SQLCipher in a c++ project. It has multiple users and each one has to have their own database credentials. Can SQLCipher do this for me? If yes, please leave a sample code. If no, please share your opinions of how to do it.
No, you cannot. It looks like SQLCipher uses a key derivation function to turn your password into a key that is applied per page of the SQLite database.
What you can do instead is the usual trick to enable multi-party encryption:
Encrypt the database with a completely random key k;
Store tuples of (user, encrypt(k, user_key)) in a file next to the database.
user_key can in turn be generated from a password using a key derivation function.
I am new to wso2 so hopefully I am not missing something obvious but we are trying to sucessfully encrypt the Connection password for a seoncary user store (\repository\deployment\server\userstores\domain.xml) and have it remain usable.
We have used the cipher tool for all our other secret information and have no issues. I have also used the cipher-tool.properties to set up a refence to the secondary user store file and got the connection password encrypted running ciphertool.bat -Dconfigure.
At that point I restart the service and viewing the logs I recieve the following error and none of my secondary user store users are available.
AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903C8, comment: AcceptSecurityContext error, data 52e, v23f0
I have double checked that the value I am encrypting is infact correct. As soon as I change it back to clear text password it works agian.
Do I have to create a custom UserStoreManager in order to acheive this?
Please try setting the alias of the property as "UserStoreManager.Property.ConnectionPassword" both in cipher-tool.properties and cipher-text.properties files.
In cipher-tool.properties
UserStoreManager.Property.ConnectionPassword=../../deployment/server/userstores/prudential.xml//UserStoreManager/Property[#name='ConnectionPassword'], true
In cipher-text.properties
UserStoreManager.Property.ConnectionPassword=[your password]
Run the cipher tool again with -Dconfigure and check.
The cipher tool cannot be used to encrypt Secondary User Store connection passwords. Instead, If you are manually adding a Secondary User Store Configuration file to
<Product_Home>/repository/deployment/server/userstores
directory, you can use the following steps to easily encrypt it.
Step 1 :
Create the Secondary User Store Configuration xml file and remove the “encrypted” attribute present in the relevant property for Connection Password as follows. Note that the password is in plain text.
<Property name=”ConnectionPassword”>admin</Property>
Step 2 :
Now rename the xml file to have a file extension of .enc as shown below.
If the name of the xml file is xyz_com.xml, rename it to
xyz_com.enc
Step 3 :
Drop the .enc file to /repository/deployment/server/userstores directory. Remember to create the “userstores” directory if it is not present.
That is all you have to do. Now you can see that the dropped file has been renamed to an xml file automatically, and when you check the file contents, the “ConnectionPassword” property has been encrypted as shown below. Note the property encrypted=“true” added to the property automatically.
<Property name=”ConnectionPassword” encrypted=”true”>eyJjIjoiTUlETUFuNEJIdjUweWNFeWQ5UThjNGx1ZTExa0NOLzJZbVExTWI3d3djRkZBUnplWmVHSXdzdFNwMTlQdmtjYjdZWHhFejdtOTJhbFFONTRKT3lIczcwNnl1WW9VaHh4d1Zmci9IL3ExWUlOOVowNERvbEZ0aExiNWRnQkhkU3luUWtxVElBc3Jydys5eEVUV1RvU3MyTTgrS0xlWkhtZW12dE1BZFRoTXVIUm9ndEJnWmVvaUxxNDAxQjk1dDgrOUd1eHN0RXE5N0R3TndwZmRlWnpnRk1VMnBEWmthMGFLckdhcTAxTlpLK1kxdG1YMWFhSlJyOGtXMlpRQW1pUm1UV1lZR0g1ZGg1OVNuV21tTzgrMW9lSFJMUU02RjdKT1dSd21xclhWdTg5aTByYWtqMk41cnJ4WGgvaGRmbVk4cmg3VkkwZkJ4M3E1eEN3YjdYRlJnXHUwMDNkXHUwMDNkIiwidCI6IlJTQS9FQ0IvT0FFUHdpdGhTSEExYW5kTUdGMVBhZGRpbmciLCJ0cCI6IjUwMUZDMTQzMkQ4NzE1NURDNDMxMzgyQUVCODQzRUQ1NThBRDYxQjEiLCJ0cGQiOiJTSEEtMSJ9</Property>
You don’t need to restart the server for these changes to be reflected. The file gets hot deployed.
You can find more information regarding encrypting Secondary User Store passwords from this article.
I have a WSO2 Goverance Registry setup conformant to this blog post http://blog.shelan.org/2013/02/application-governance-with-wso2-greg.html.
When defining a new application in the WSO2 GR using the menu: Metadata > Add > Application I would like to be able to directly add the actual application artifact (war/car file).
The selected file should then by placed in the SVN location conforming to the initial state of the lifecycle to which I will bind the application. This of course implies that I would also need to be able to directly add the lifecycle when defining a new application.
The new application form would then be something like this:
Name: ExampleApplication-1.0.0
Type: .war (is now redundant)
Description: My Example Application Artifact: Selected file
ExampleApplication-1.0.0.war Lifecyle: MyDTAP-Lifecycle_v1
Does anybody know a good starting point for adding this functionality in terms of code hooks or extension points?
If I have understood you correctly, what you need to do is basically provide an file upload option in your "Application" RXT (Governance Artifact Configuration) which will upload what ever your file type and based on that you want to fill the derivable information to the meta data of the artifact. And also to attach a selected/pre defined life cycle to it at artifact creation. What you are looking for is Registry Handlers [1]. You can achieve all aforementioned tasks probably through a single handler.
[1] - http://docs.wso2.org/wiki/display/Governance453/Handlers