David E Jones wrote: > On Mar 16, 2010, at 2:13 PM, Adam Heath wrote: > >> [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. > > I'm not sure what you mean by this.
You're right. I read it wrong. I thought this was the user login password field needed to be encrypted in the tenant database. Sorry about that. (I still haven't had time to look at the branch)
