[
https://issues.apache.org/jira/browse/SOLR-4392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-4392:
-----------------------------
Description:
Today, the connection (database or otherwise) credentials is wide open in
data-config.xml. Not really an issue until someone sends out the config file
outside of the server.
We should look into externalizing the database lookup or providing a way to
encrypt the username and password.
The needs are:
1/ Some projects want to enable multi-tenancy where data for each core is
situated in different database servers w/ their own credentials. We need a way
to expose hooks that will allow implementations to be plugged in. It can be
done though the "type" attribute on the dataSource, but providing a factory
might work better.
2/ Most orgs are very protective of their credentials and weary of plain-text
settings.
{code:xml}
<dataSource name="jdbc" driver="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@//hostname:port/SID" user="db_username"
<!-- This database password is encrypted using AES using the command. pwd.txt
contains the actual DB password -->
<!-- openssl enc -aes-128-cbc -a -salt -in pwd.txt -->
password="U2FsdGVkX18QMjY0yfCqlfBMvAB4d3XkwY96L7gfO2o="
<!-- Password to decrypt is stored in this file-->
encryptKeyFile="/location/of/encryptionkey"
/>
{code}
was:
Today, the connection (database or otherwise) credentials is wide open in
data-config.xml. Not really an issue until someone sends out the config file
outside of the server.
We should look into externalizing the database lookup or providing a way to
encrypt the username and password.
The needs are:
1/ Some projects want to enable multi-tenancy where data for each core is
situated in different database servers w/ their own credentials. We need a way
to expose hooks that will allow implementations to be plugged in. It can be
done though the "type" attribute on the dataSource, but providing a factory
might work better.
2/ Most orgs are very protective of their credentials and weary of plain-text
settings.
> DIH - Need to externalize or encrypt username/password stored within
> data-config.xml
> ------------------------------------------------------------------------------------
>
> Key: SOLR-4392
> URL: https://issues.apache.org/jira/browse/SOLR-4392
> Project: Solr
> Issue Type: New Feature
> Components: contrib - DataImportHandler
> Affects Versions: 4.0, 4.1
> Reporter: Senthuran Sivananthan
> Assignee: Noble Paul
> Fix For: Trunk, 5.2
>
> Attachments: SOLR-4392.patch, SOLR-4392.patch
>
>
> Today, the connection (database or otherwise) credentials is wide open in
> data-config.xml. Not really an issue until someone sends out the config file
> outside of the server.
> We should look into externalizing the database lookup or providing a way to
> encrypt the username and password.
> The needs are:
> 1/ Some projects want to enable multi-tenancy where data for each core is
> situated in different database servers w/ their own credentials. We need a
> way to expose hooks that will allow implementations to be plugged in. It can
> be done though the "type" attribute on the dataSource, but providing a
> factory might work better.
> 2/ Most orgs are very protective of their credentials and weary of
> plain-text settings.
> {code:xml}
> <dataSource name="jdbc" driver="oracle.jdbc.driver.OracleDriver"
> url="jdbc:oracle:thin:@//hostname:port/SID" user="db_username"
> <!-- This database password is encrypted using AES using the command. pwd.txt
> contains the actual DB password -->
> <!-- openssl enc -aes-128-cbc -a -salt -in pwd.txt -->
> password="U2FsdGVkX18QMjY0yfCqlfBMvAB4d3XkwY96L7gfO2o="
> <!-- Password to decrypt is stored in this file-->
> encryptKeyFile="/location/of/encryptionkey"
> />
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
