OFBiz
  1. OFBiz
  2. OFBIZ-4130

Tenant super user (tenant admin) can view all database details of all tenants

    Details

      Description

      When a new tenant is created and the super user of the tenant (the tenant-admin) logs in to WebTools and views the tables Tenant and TenantDataSource he/she can see all details of the tenant databases, incl TenantName, userID and password of the tenant databases.

      1. meta-tenant-db.patch
        13 kB
        Jacopo Cappellato
      2. error.log
        104 kB
        Pierre Smits
      3. meta-tenant-db.patch
        5 kB
        Jacopo Cappellato
      4. OFBIZ-4130-MultiTenant-visibilty.patch
        0.9 kB
        Pierre Smits

        Issue Links

          Activity

          Hide
          Pierre Smits added a comment -

          Jacopo,
          I noticed (at first glance) the conflicts on 12.04 too.

          Given that not many have stated using r11 or r12 for multi-tenancy my advice would be not using those releases for this aspect.

          Thanks for fixing this.

          Show
          Pierre Smits added a comment - Jacopo, I noticed (at first glance) the conflicts on 12.04 too. Given that not many have stated using r11 or r12 for multi-tenancy my advice would be not using those releases for this aspect. Thanks for fixing this.
          Hide
          Jacopo Cappellato added a comment -

          Thanks for your tests Pierre.
          Committed in rev. 1589589 (trunk) and 1589592 (13.07); I got conflicts on 12.04 and 11.04 and I didn't back port to these release branches; if no one will backport these changes there, for users of 11.04 and 12.04 releases the (sub-optimal) solution is to prevent access to the Webtools to tenant users.

          Show
          Jacopo Cappellato added a comment - Thanks for your tests Pierre. Committed in rev. 1589589 (trunk) and 1589592 (13.07); I got conflicts on 12.04 and 11.04 and I didn't back port to these release branches; if no one will backport these changes there, for users of 11.04 and 12.04 releases the (sub-optimal) solution is to prevent access to the Webtools to tenant users.
          Hide
          Pierre Smits added a comment -

          I tested it against trunk, with no errors while creating and accessing a new tenant.

          Show
          Pierre Smits added a comment - I tested it against trunk, with no errors while creating and accessing a new tenant.
          Hide
          Pierre Smits added a comment -

          Thank you for the update, Jacopo.

          I will test it over the weekend and get back in the course of next week.

          Show
          Pierre Smits added a comment - Thank you for the update, Jacopo. I will test it over the weekend and get back in the course of next week.
          Hide
          Jacopo Cappellato added a comment -

          Thank you for your tests Pierre, they have helped: I have enhanced the code that was causing these problems and the new version should work better.
          Please find the attached new meta-tenant-db.patch: it would be useful if you can test it again after reverting the previous one.

          Show
          Jacopo Cappellato added a comment - Thank you for your tests Pierre, they have helped: I have enhanced the code that was causing these problems and the new version should work better. Please find the attached new meta-tenant-db.patch: it would be useful if you can test it again after reverting the previous one.
          Hide
          Pierre Smits added a comment -

          When accessing the tenant by logging in as tenant-admin, after a restart, I see following error:

          2014-03-30 16:08:36,553 (http-bio-0.0.0.0-8443-exec-1) [ ExecutionPool.java:87 :ERROR]
          ---- exception report ----------------------------------------------------------
          Exception: java.util.concurrent.ExecutionException
          Message: java.lang.NullPointerException
          ---- cause ---------------------------------------------------------------------
          Exception: java.lang.NullPointerException
          Message: null
          ---- stack trace ---------------------------------------------------------------
          java.lang.NullPointerException
          org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:264)
          org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:88)
          org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:293)
          org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:290)
          java.util.concurrent.FutureTask.run(FutureTask.java:262)
          java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
          java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
          java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          java.lang.Thread.run(Thread.java:744)
          --------------------------------------------------------------------------------

          Show
          Pierre Smits added a comment - When accessing the tenant by logging in as tenant-admin, after a restart, I see following error: 2014-03-30 16:08:36,553 (http-bio-0.0.0.0-8443-exec-1) [ ExecutionPool.java:87 :ERROR] ---- exception report ---------------------------------------------------------- Exception: java.util.concurrent.ExecutionException Message: java.lang.NullPointerException ---- cause --------------------------------------------------------------------- Exception: java.lang.NullPointerException Message: null ---- stack trace --------------------------------------------------------------- java.lang.NullPointerException org.ofbiz.entity.GenericDelegator.initializeOneGenericHelper(GenericDelegator.java:264) org.ofbiz.entity.GenericDelegator.access$000(GenericDelegator.java:88) org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:293) org.ofbiz.entity.GenericDelegator$1.call(GenericDelegator.java:290) java.util.concurrent.FutureTask.run(FutureTask.java:262) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) java.lang.Thread.run(Thread.java:744) --------------------------------------------------------------------------------
          Hide
          Pierre Smits added a comment -

          When creating a new tenant with ./ant create-tenant after having applied meta-tenant-db.patch a lot of errors are generated. As can be seen in attached error.log file.
          I have set the parameters of the create-tenant actions to load the seed data into the database of the tenant in the Derby rdbms.

          The errors are typically:
          Failure in findOne operation for entity [Component]: org.ofbiz.entity.GenericEntityException: There is no datasource (Helper) configured for the entity-group [org.ofbiz.tenant]; wa$
          Exception: org.ofbiz.entity.GenericEntityException
          Message: There is no datasource (Helper) configured for the entity-group [org.ofbiz.tenant]; was trying to find datesource (helper) for entity [Component]

          After a ./ant start I see the Tenant and the TenantDatasource when accessing the setup with the (general) admin account.
          When using the tenant-admin id to log into the tenant I can access the entity data maintenance functionality. I don't see the Tenant, the TenantComponent and TenantDatasource tables. However, I see the TenantKeyEncryptionKey table. I am not sure whether this should happen or not.

          • Importing seed data through 'xml import data readers as a tenant-admin in a tenant generated no errors.
          • Importing seed-initial data through 'xml import data readers as a tenant-admin in a tenant generated no errors.
          • Importing seed-ext data through 'xml import data readers as a tenant-admin in a tenant generated no errors, as there was no data.
          • Importing demo data through 'xml import data readers as a tenant-admin in a tenant generated an error on 'TenantDemoData.xml', which is to be expected as it tries to enter data into the Tenant and TenantDatasource tables where the tenant-admin id has no access to.

          The error generated are in the same line as stated above.

          Show
          Pierre Smits added a comment - When creating a new tenant with ./ant create-tenant after having applied meta-tenant-db.patch a lot of errors are generated. As can be seen in attached error.log file. I have set the parameters of the create-tenant actions to load the seed data into the database of the tenant in the Derby rdbms. The errors are typically: Failure in findOne operation for entity [Component] : org.ofbiz.entity.GenericEntityException: There is no datasource (Helper) configured for the entity-group [org.ofbiz.tenant] ; wa$ Exception: org.ofbiz.entity.GenericEntityException Message: There is no datasource (Helper) configured for the entity-group [org.ofbiz.tenant] ; was trying to find datesource (helper) for entity [Component] After a ./ant start I see the Tenant and the TenantDatasource when accessing the setup with the (general) admin account. When using the tenant-admin id to log into the tenant I can access the entity data maintenance functionality. I don't see the Tenant, the TenantComponent and TenantDatasource tables. However, I see the TenantKeyEncryptionKey table. I am not sure whether this should happen or not. Importing seed data through 'xml import data readers as a tenant-admin in a tenant generated no errors. Importing seed-initial data through 'xml import data readers as a tenant-admin in a tenant generated no errors. Importing seed-ext data through 'xml import data readers as a tenant-admin in a tenant generated no errors, as there was no data. Importing demo data through 'xml import data readers as a tenant-admin in a tenant generated an error on 'TenantDemoData.xml', which is to be expected as it tries to enter data into the Tenant and TenantDatasource tables where the tenant-admin id has no access to. The error generated are in the same line as stated above.
          Hide
          Pierre Smits added a comment -

          Thanks Jacopo,

          I will test this over the weekend and will share the result next week.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Thanks Jacopo, I will test this over the weekend and will share the result next week. Regards, Pierre
          Hide
          Jacopo Cappellato added a comment -

          I had finally time to dig into this problem.
          There is indeed an issue (as reported by Pierre) in the code written by Hans; however (as commented by Hans) the solution/fix proposed by Pierre is wrong.
          Please find the attached patch that should fix the issue in the proper way.
          From what I understand you both are selling services based on the multi-tenant features of OFBiz: so please test it and let me know if it can be committed to the trunk (and release branches).
          I hope this solution will set an end to this never-ending story.

          Show
          Jacopo Cappellato added a comment - I had finally time to dig into this problem. There is indeed an issue (as reported by Pierre) in the code written by Hans; however (as commented by Hans) the solution/fix proposed by Pierre is wrong. Please find the attached patch that should fix the issue in the proper way. From what I understand you both are selling services based on the multi-tenant features of OFBiz: so please test it and let me know if it can be committed to the trunk (and release branches). I hope this solution will set an end to this never-ending story.
          Hide
          Pierre Smits added a comment - - edited

          Hans said: 'I would not make the webtools application available to tenants'.

          Unfortunately, many aspects of keyword maintenance are only accessible through the webtools application. This is the result of having no configuration options in the various apps and components. Thus we can't avoid granting tenant super users access to webtools.

          But, apart from that issue (improvement) we should ensure that tenant super users don't see tenant configuration details of other tenants.

          Show
          Pierre Smits added a comment - - edited Hans said: 'I would not make the webtools application available to tenants'. Unfortunately, many aspects of keyword maintenance are only accessible through the webtools application. This is the result of having no configuration options in the various apps and components. Thus we can't avoid granting tenant super users access to webtools. But, apart from that issue (improvement) we should ensure that tenant super users don't see tenant configuration details of other tenants.
          Hide
          Jacques Le Roux added a comment -

          Pierre told me

          Way to test is: first create 2 new tenants with ./ant create-tenant and login as the super user of one. Go to tenantdatasource and observe that you'll see all sources. Apply patch, and log in again. Observe that you can't see the tenantdatasource.

          Show
          Jacques Le Roux added a comment - Pierre told me Way to test is: first create 2 new tenants with ./ant create-tenant and login as the super user of one. Go to tenantdatasource and observe that you'll see all sources. Apply patch, and log in again. Observe that you can't see the tenantdatasource.
          Hide
          Hans Bakker added a comment -

          Hi Jacopo, as you probably saw in the mailinglist we are very busy here and can currently not help much.
          With the current multi tenant implementation I would not make the webtools application available to tenants.

          Regards,
          Hans

          Show
          Hans Bakker added a comment - Hi Jacopo, as you probably saw in the mailinglist we are very busy here and can currently not help much. With the current multi tenant implementation I would not make the webtools application available to tenants. Regards, Hans
          Hide
          Jacopo Cappellato added a comment -

          Hans,

          unfortunately I don't know much about this code, but I would like to try to help to resolve in some way this ticket.
          If I well understand, the issue reported here is that, if a tenant user is granted the role of 'SECURITYADMIN' then it has access to the data of other tenants.
          How would you classify this, according to your design? Is it a bug (but the solution proposed is not good)? Is it an intended feature by design (i.e. SECURITYADMIN should be used to create a superuser, that can manage all tenants)? Is it a side effect of the design (i.e. SECURITYADMIN should never be used for tenant users)?
          If I understand this then I can probably be of some help.

          Show
          Jacopo Cappellato added a comment - Hans, unfortunately I don't know much about this code, but I would like to try to help to resolve in some way this ticket. If I well understand, the issue reported here is that, if a tenant user is granted the role of 'SECURITYADMIN' then it has access to the data of other tenants. How would you classify this, according to your design? Is it a bug (but the solution proposed is not good)? Is it an intended feature by design (i.e. SECURITYADMIN should be used to create a superuser, that can manage all tenants)? Is it a side effect of the design (i.e. SECURITYADMIN should never be used for tenant users)? If I understand this then I can probably be of some help.
          Hide
          Pierre Smits added a comment -

          Keeping it together. I accidentally replied directly in the dev ML, not doing it from here.

          Only for non-default delegators (read delegators for tenants). As you know each tenant gets his own delegator. However, current setup of OFBiz doesn't have tenant users look at the data in the tenant delegator for the tables mentioned, but in the main delegator.

          And that is why each tenant user with access to webtools has access to the data concerning all tenants, like tenant id and name, the setup of the databases of each tenant, the domain name and the components used by the other tenants.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Keeping it together. I accidentally replied directly in the dev ML, not doing it from here. Only for non-default delegators (read delegators for tenants). As you know each tenant gets his own delegator. However, current setup of OFBiz doesn't have tenant users look at the data in the tenant delegator for the tables mentioned, but in the main delegator. And that is why each tenant user with access to webtools has access to the data concerning all tenants, like tenant id and name, the setup of the databases of each tenant, the domain name and the components used by the other tenants. Regards, Pierre
          Hide
          Hans Bakker added a comment -

          doesn't this patch effect both default or non-default delegator? Not sure how this can help.

          Show
          Hans Bakker added a comment - doesn't this patch effect both default or non-default delegator? Not sure how this can help.
          Hide
          Pierre Smits added a comment -

          Hans,

          I believe you do not fully understand the issue at hand. I am NOT talking about the admin (as you call it the super tenant user) of the main delegator, who indeed must be able to administer and add tenants.

          I am talking about users of tenants who have been granted the role of 'SECURITYADMIN' to manage/maintain data thru webtools for their own tenant. These users can see details of all tenants in tables 'Tenant', TenantComponent' and 'TenantDataSource'. And that is a situation you would not want.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Hans, I believe you do not fully understand the issue at hand. I am NOT talking about the admin (as you call it the super tenant user) of the main delegator, who indeed must be able to administer and add tenants. I am talking about users of tenants who have been granted the role of 'SECURITYADMIN' to manage/maintain data thru webtools for their own tenant. These users can see details of all tenants in tables 'Tenant', TenantComponent' and 'TenantDataSource'. And that is a situation you would not want. Regards, Pierre
          Hide
          Hans Bakker added a comment - - edited

          I am against this patch. The super tenant user can see all other tenants, is fine, somebody has to administer and be able to add tenants.

          Show
          Hans Bakker added a comment - - edited I am against this patch. The super tenant user can see all other tenants, is fine, somebody has to administer and be able to add tenants.
          Hide
          Pierre Smits added a comment -

          This patch fixes the issue that tenant-admins with access to webtools can see other tenants

          Show
          Pierre Smits added a comment - This patch fixes the issue that tenant-admins with access to webtools can see other tenants
          Hide
          Pierre Smits added a comment -

          I believe that the following piece of code in framework/entity/src/org/ofbiz/entity/GenericDelegator.Java is the culprit:

          // to avoid infinite recursion, and to behave right for shared org.ofbiz.tenant entities, do nothing with the tenantId if the entityGroupName=org.ofbiz.tenant
          if (UtilValidate.isNotEmpty(this.delegatorTenantId) && !"org.ofbiz.tenant".equals(entityGroupName)) {
          helperInfo.setTenantId(this.delegatorTenantId);

          // get the JDBC parameters from the DB for the entityGroupName and tenantId
          try {
          // NOTE: instead of caching the GenericHelpInfo object do a cached query here and create a new object each time, will avoid issues when the database data changes during run time
          // NOTE: always use the base delegator for this to avoid problems when this is being initialized
          Delegator baseDelegator = DelegatorFactory.getDelegator(this.delegatorBaseName);
          GenericValue tenantDataSource = baseDelegator.findOne("TenantDataSource", true, "tenantId", this.delegatorTenantId, "entityGroupName", entityGroupName);
          if (tenantDataSource != null)

          { helperInfo.setOverrideJdbcUri(tenantDataSource.getString("jdbcUri")); helperInfo.setOverrideUsername(tenantDataSource.getString("jdbcUsername")); helperInfo.setOverridePassword(tenantDataSource.getString("jdbcPassword")); }

          else {
          /* don't log this, happens too many times:
          if (Debug.warningOn())

          { Debug.logWarning("Could not find TenantDataSource information for tenantId=[" + this.delegatorTenantId + "] and entityGroupName=[" + entityGroupName + "] in delegator [" + this.delegatorFullName + "]; will be defaulting to settings for the base delegator name [" + this.delegatorBaseName + "]", module); }

          */
          }
          } catch (GenericEntityException e)

          { // don't complain about this too much, just log the error if there is one Debug.logInfo(e, "Error getting TenantDataSource info for tenantId=" + this.delegatorTenantId + ", entityGroupName=" + entityGroupName, module); }

          }

          Especially the remark at the top lead to this construction. But it is a wrong assumption. When used with production databases, like MySQL and PostgreSQL, just adding data through manual processes in webtools or even using ant targets do not create the recursions talked about. Only the organization in control of the OFBiz instance and having access to the underlying systems can create new tenants.

          Show
          Pierre Smits added a comment - I believe that the following piece of code in framework/entity/src/org/ofbiz/entity/GenericDelegator.Java is the culprit: // to avoid infinite recursion, and to behave right for shared org.ofbiz.tenant entities, do nothing with the tenantId if the entityGroupName=org.ofbiz.tenant if (UtilValidate.isNotEmpty(this.delegatorTenantId) && !"org.ofbiz.tenant".equals(entityGroupName)) { helperInfo.setTenantId(this.delegatorTenantId); // get the JDBC parameters from the DB for the entityGroupName and tenantId try { // NOTE: instead of caching the GenericHelpInfo object do a cached query here and create a new object each time, will avoid issues when the database data changes during run time // NOTE: always use the base delegator for this to avoid problems when this is being initialized Delegator baseDelegator = DelegatorFactory.getDelegator(this.delegatorBaseName); GenericValue tenantDataSource = baseDelegator.findOne("TenantDataSource", true, "tenantId", this.delegatorTenantId, "entityGroupName", entityGroupName); if (tenantDataSource != null) { helperInfo.setOverrideJdbcUri(tenantDataSource.getString("jdbcUri")); helperInfo.setOverrideUsername(tenantDataSource.getString("jdbcUsername")); helperInfo.setOverridePassword(tenantDataSource.getString("jdbcPassword")); } else { /* don't log this, happens too many times: if (Debug.warningOn()) { Debug.logWarning("Could not find TenantDataSource information for tenantId=[" + this.delegatorTenantId + "] and entityGroupName=[" + entityGroupName + "] in delegator [" + this.delegatorFullName + "]; will be defaulting to settings for the base delegator name [" + this.delegatorBaseName + "]", module); } */ } } catch (GenericEntityException e) { // don't complain about this too much, just log the error if there is one Debug.logInfo(e, "Error getting TenantDataSource info for tenantId=" + this.delegatorTenantId + ", entityGroupName=" + entityGroupName, module); } } Especially the remark at the top lead to this construction. But it is a wrong assumption. When used with production databases, like MySQL and PostgreSQL, just adding data through manual processes in webtools or even using ant targets do not create the recursions talked about. Only the organization in control of the OFBiz instance and having access to the underlying systems can create new tenants.
          Hide
          Pierre Smits added a comment -

          Defus,

          You changed the status of this issue to Patch Available, but you did not provide the patch. Can you please do so? I will then evaluate as soon as possible.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Defus, You changed the status of this issue to Patch Available, but you did not provide the patch. Can you please do so? I will then evaluate as soon as possible. Regards, Pierre
          Hide
          Hans Bakker added a comment -

          Pierre,

          ofbizsaas.com is just a demosystem of the tenant functions within ofbiz. No modifications were done in the access logic of these tenant tables.

          Regards,
          Hans

          Show
          Hans Bakker added a comment - Pierre, ofbizsaas.com is just a demosystem of the tenant functions within ofbiz. No modifications were done in the access logic of these tenant tables. Regards, Hans
          Hide
          Pierre Smits added a comment -

          First of all: ofbizsaas.com is not endorsed by the Apache OFBiz project, but (probably) a customized instance of a version of OFBiz and owned by Ant Websystems Co. Ltd.

          Second:
          If users execute following procedure when installing OFBiz trunk (in this case on either MAC or LINUX):

          • ./ant run-install-extseed
          • ./ant create-admin-user-login
          • ./ant run-create-tenant (for tenant #1)
          • ./ant run-create-tenant (for tenant #2)
          • set 'multitenant'=Y in 'framework/common/config/general.properties'
          • and subsequently start OFBiz with ./startofbiz.sh
          • and login with either the admin account for tenant #1 or the admin account for tenant #2
          • and access table 'tenant' or table 'TenantDataSource' in entity data management via 'Framework Web Tools'

          the user will see all registered tenants and associated tenantdata sources. So does any ohter party created in a tenant who has 'SECURITYADMIN' permissions.

          I think that such a situation is unwanted and poses great risks.

          Show
          Pierre Smits added a comment - First of all: ofbizsaas.com is not endorsed by the Apache OFBiz project, but (probably) a customized instance of a version of OFBiz and owned by Ant Websystems Co. Ltd. Second: If users execute following procedure when installing OFBiz trunk (in this case on either MAC or LINUX): ./ant run-install-extseed ./ant create-admin-user-login ./ant run-create-tenant (for tenant #1) ./ant run-create-tenant (for tenant #2) set 'multitenant'=Y in 'framework/common/config/general.properties' and subsequently start OFBiz with ./startofbiz.sh and login with either the admin account for tenant #1 or the admin account for tenant #2 and access table 'tenant' or table 'TenantDataSource' in entity data management via 'Framework Web Tools' the user will see all registered tenants and associated tenantdata sources. So does any ohter party created in a tenant who has 'SECURITYADMIN' permissions. I think that such a situation is unwanted and poses great risks.
          Hide
          Hans Bakker added a comment - - edited

          please read what i wrote:

          The super tenant user can see all tenants while the tenants themselves can only see their own tenant record.

          means a tenant with a tenantid can only see his own tenant records.
          A super tenant, actually which is using the default delegator can see the info of all tenants, which is fine.

          please go to http://ofbizsaas.com register yourself, you will get a tenant created for you and you can check it out......

          Regards,
          Hans

          Show
          Hans Bakker added a comment - - edited please read what i wrote: The super tenant user can see all tenants while the tenants themselves can only see their own tenant record. means a tenant with a tenantid can only see his own tenant records. A super tenant, actually which is using the default delegator can see the info of all tenants, which is fine. please go to http://ofbizsaas.com register yourself, you will get a tenant created for you and you can check it out...... Regards, Hans
          Hide
          Pierre Smits added a comment -

          So what you're saying it is ok that when you provide one of the employees of your tenant access to framework tools to do entity data management on the backend he can also find out who your other tenants are?

          And via the tenant-ID and some (minor) effort can get access to the data of your other tenants?

          Show
          Pierre Smits added a comment - So what you're saying it is ok that when you provide one of the employees of your tenant access to framework tools to do entity data management on the backend he can also find out who your other tenants are? And via the tenant-ID and some (minor) effort can get access to the data of your other tenants?
          Hide
          Hans Bakker added a comment -

          It think tis is fine as the way it is at the moment:
          The super tenant user can see all tenants while the tenants themselves can only see their own tenant records.
          You will always need a function which has general access related to tenant info.
          Other info cannot be seen by the tenant admin, although this user has normally server access and read the database directly.....

          I propose to close this issue.

          Regards,
          Hans

          Show
          Hans Bakker added a comment - It think tis is fine as the way it is at the moment: The super tenant user can see all tenants while the tenants themselves can only see their own tenant records. You will always need a function which has general access related to tenant info. Other info cannot be seen by the tenant admin, although this user has normally server access and read the database directly..... I propose to close this issue. Regards, Hans
          Hide
          Pierre Smits added a comment -

          Hi Jacques,

          Yes please, As this a mayor bug that influences the deployment as a multi-tenant solution. Plus no solution hasn't been provided yet.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Hi Jacques, Yes please, As this a mayor bug that influences the deployment as a multi-tenant solution. Plus no solution hasn't been provided yet. Regards, Pierre
          Hide
          Jacques Le Roux added a comment -

          Pierre,

          Should we keep open?

          Show
          Jacques Le Roux added a comment - Pierre, Should we keep open?
          Hide
          BJ Freeman added a comment -
          Show
          BJ Freeman added a comment - I found this thread http://osdir.com/ml/dev.ofbiz.apache.org/2010-03/msg01665.html
          Hide
          BJ Freeman added a comment -

          i did not do a patch so can't tell you what I changed it was last year.
          when I get time will review and inform you.

          Show
          BJ Freeman added a comment - i did not do a patch so can't tell you what I changed it was last year. when I get time will review and inform you.
          Hide
          BJ Freeman added a comment -
          Show
          BJ Freeman added a comment - you might look at this also http://ofbiz.apache.org/docs/serviceconfig.html#ThreadPool
          Hide
          Pierre Smits added a comment -

          Hi BJ,

          Can you inform me which line in the seed data enables tenant-admins to view data in the tables 'Tenant' and 'TenantDataSource'?

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Hi BJ, Can you inform me which line in the seed data enables tenant-admins to view data in the tables 'Tenant' and 'TenantDataSource'? Regards, Pierre
          Hide
          BJ Freeman added a comment -

          actually this is because the same seed data is loaded into each tenant database.
          as I commented on the dev ml, there should be separate seed data for tenants
          from the base seed data that gets loaded when ofbiz is first created.
          I did this by adding a tenant reader and separating base seed data from tenant seed data.

          Show
          BJ Freeman added a comment - actually this is because the same seed data is loaded into each tenant database. as I commented on the dev ml, there should be separate seed data for tenants from the base seed data that gets loaded when ofbiz is first created. I did this by adding a tenant reader and separating base seed data from tenant seed data.
          Hide
          Jacques Le Roux added a comment -

          I'd suggest to discuss this on dev ML, it would maybe get a better attention.

          Show
          Jacques Le Roux added a comment - I'd suggest to discuss this on dev ML, it would maybe get a better attention.
          Hide
          Pierre Smits added a comment -

          Hi all,

          I would like to resolve this. But before doing so I would like your feedback regarding this issue and the best approach.

          Regards,

          Pierre

          Show
          Pierre Smits added a comment - Hi all, I would like to resolve this. But before doing so I would like your feedback regarding this issue and the best approach. Regards, Pierre
          Hide
          Pierre Smits added a comment -

          Moved Priority to critical. As this undermines the roll-out of OFBiz as multi tenancy solution.

          Show
          Pierre Smits added a comment - Moved Priority to critical. As this undermines the roll-out of OFBiz as multi tenancy solution.
          Hide
          Pierre Smits added a comment -

          Currently the tenant tables (tables Tenant and TenantDataSource), not the tables for the tenant, are accessed through delegator org.ofbiz.tenant.
          One solution is, that like other database tables, these tables will be accessed trhough the standard delegator org.ofbiz. The tenant admins (with FULLADMIN rights in the tenant environment) then can no longer see the data in the tables of the master databases.

          However, they then can create new data entries in the tables in their own tenant environment.

          Show
          Pierre Smits added a comment - Currently the tenant tables (tables Tenant and TenantDataSource), not the tables for the tenant, are accessed through delegator org.ofbiz.tenant. One solution is, that like other database tables, these tables will be accessed trhough the standard delegator org.ofbiz. The tenant admins (with FULLADMIN rights in the tenant environment) then can no longer see the data in the tables of the master databases. However, they then can create new data entries in the tables in their own tenant environment.
          Hide
          Pierre Smits added a comment -

          This will also affect multi tenancy in version 10.04.

          Show
          Pierre Smits added a comment - This will also affect multi tenancy in version 10.04.

            People

            • Assignee:
              Jacopo Cappellato
              Reporter:
              Pierre Smits
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development