[email protected] wrote:
> Author: jonesde
> Date: Tue Mar 16 19:02:06 2010
> New Revision: 923939
> 
> URL: http://svn.apache.org/viewvc?rev=923939&view=rev
> Log:
> Removed encrypt=true for the jdbc password with a comment about why; 
> encrypting this field can be reintroduced, preferably when that issue is 
> resolved
> 
> Modified:
>     
> ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
> 
> Modified: 
> ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
> URL: 
> http://svn.apache.org/viewvc/ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml?rev=923939&r1=923938&r2=923939&view=diff
> ==============================================================================
> --- 
> ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml 
> (original)
> +++ 
> ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml 
> Tue Mar 16 19:02:06 2010
> @@ -80,7 +80,14 @@ under the License.
>          <field name="entityGroupName" type="name"/>
>          <field name="jdbcUri" type="long-varchar"/>
>          <field name="jdbcUsername" type="long-varchar"/>
> -        <field name="jdbcPassword" type="long-varchar" encrypt="true"/>
> +        <field name="jdbcPassword" type="long-varchar">
> +            <!-- This field should probably be encrypted, but the 
> encrypt=true attribute will not work in this case
> +            because different tenants will have different sets of encryption 
> keys because the EntityKeyStore table is
> +            in the per-tenant database an not in the shared tenant control 
> database, which causes different keys to
> +            be used for those logged in under different tenants, causing 
> decryption errors unless you do all 
> +            TenantDataSource maintenance from only one tenant (or the 
> non-tenant master db). Removing that for now 
> +            until this issue is resolved, possibly by moving the 
> EntityKeyStore entity into the tenant database. -->
> +        </field>
>          <prim-key field="tenantId"/>
>          <prim-key field="entityGroupName"/>
>          <relation type="one" fk-name="TNTDTSRC_TNT" rel-entity-name="Tenant">
> 

If the username matches, then do a pre-emptive looking into the tenant
database, to find the right key, then go back and do a decrypt?

Of course, you may already be thinking that, but this code is not just
as simple as snapping one's fingers.

Reply via email to