You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@gmail.com> on 2014/03/01 00:38:51 UTC
Re: Planning the next releases
Jacopo,
Jou said:
the main design around the entities in the org.ofbiz.tenant group is the
following: one separate small database is created to host all and only the
org.ofbiz.tenant entities: these entities contain meta-data information for
all tenants (url, db user and password to get access to each tenant db).
That is what I am saying. The database containing the details about each
tenant should only be accessible from the master, and not from each tenant.
Without the patch the super user of any tenant can see the details (of
every other tenant) in the tables tenant and tenantdatasource of that
database. And this shouldn't be.
The patch will ensure that only through the master the db and these tables
are accessible.
Regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Fri, Feb 28, 2014 at 5:10 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> wrote:
> I have spent some time reviewing a part of the code and I have a few
> comments inline:
>
> On Feb 25, 2014, at 10:48 PM, Pierre Smits <pi...@gmail.com> wrote:
>
> > Jacopo,
> >
> > I also would like to understand what that means. And what I don't
> > understand I can't recreate it also.
>
> the main design around the entities in the org.ofbiz.tenant group is the
> following: one separate small database is created to host all and only the
> org.ofbiz.tenant entities: these entities contain meta-data information for
> all tenants (url, db user and password to get access to each tenant db).
> The patch you have proposed, by removing the org.ofbiz.tenant group, has
> the effect of moving these entities to the main OFBiz database: could you
> please check if you see these entities in your local box (with your patch
> applied)? Also, could you please check the content of these entities in the
> tenant specific databases and in the main database?
>
> >
> > As far as conditions go, I will elaborate here under what conditions we
> > have tested the patch.
> >
> > We created a virtual test setup consisting of 1 webserver (Apache HTTP)
> and
> > 1 app server (consisting of Apache OFBiz, set up against derby) whereby
> the
> > connection and traffic between the 2 servers was with and through the AJP
> > protocol.
> >
> > In that setup we created 5 tenants (with ./ant create-tenant).
> > And without the patch we tested all tenants accessing various apps and
> > components with Apache JMeter (and scripts). This included accessing
> > various functions in webtools as well.
>
> Are you saying that when you log in into Webtools with a tenantId you
> actually see the data from the main database rather than the data from the
> tenant specific db only? Is this happening for all the entities or just (as
> I suspect) for the entities in the org.ofbiz.tenant group?
>
> Jacopo
>
> >
> > Subsequently, we implemented the patch and ran the same tests again.
> Again
> > we had no problems accessing the various apps and components. The only
> > thing we didn't succeed in was accessing Tenant and TenantDataSource,
> when
> > being logged in as a tenant super-user.
> > However, when logged in as the admin of the master (without tenantId) we
> > were abel to access those entities and its data.
> >
> > Both situations, being able to access the two entities and the data when
> > logged in as master admin and not being able to when logged in as a
> > tenant-admin, are as to be expected.
> >
> > Now, I don't know what that means when having set up the domain name for
> a
> > tenant as the means to access the tenant environment. Apparently that has
> > been developed to have a unique uri per tenant. But we never have had any
> > use for that as we in our 3-tier productions setups have it as described
> as
> > above. This avoids us having to set up internal dns records to point to
> > specific tenants to connect to the app server.
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
>
>
Re: Planning the next releases
Posted by Jacques Le Roux <ja...@les7arts.com>.
OK, forget it. I got a wrong configuration. Actually in standard case all is working as expected, nothing more is needed.
Jacques
Le 04/03/2014 12:25, Jacques Le Roux a écrit :
> Hi Jacopo,
>
> I just spotted something I want to put in 13.07. It's about demos and stopping and instance launched with a portoffset value.
> I want to adapt status and stop ant targets. To pass them a portoffset to allow knowing the instance status or stopping it...
>
> I should do that soon...
>
> Thanks
>
> Jacques
>
>
> Le 01/03/2014 00:38, Pierre Smits a écrit :
>> Jacopo,
>>
>> Jou said:
>>
>> the main design around the entities in the org.ofbiz.tenant group is the
>> following: one separate small database is created to host all and only the
>> org.ofbiz.tenant entities: these entities contain meta-data information for
>> all tenants (url, db user and password to get access to each tenant db).
>>
>>
>> That is what I am saying. The database containing the details about each
>> tenant should only be accessible from the master, and not from each tenant.
>>
>> Without the patch the super user of any tenant can see the details (of
>> every other tenant) in the tables tenant and tenantdatasource of that
>> database. And this shouldn't be.
>>
>> The patch will ensure that only through the master the db and these tables
>> are accessible.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>
>> On Fri, Feb 28, 2014 at 5:10 PM, Jacopo Cappellato <
>> jacopo.cappellato@hotwaxmedia.com> wrote:
>>
>>> I have spent some time reviewing a part of the code and I have a few
>>> comments inline:
>>>
>>> On Feb 25, 2014, at 10:48 PM, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>>> Jacopo,
>>>>
>>>> I also would like to understand what that means. And what I don't
>>>> understand I can't recreate it also.
>>> the main design around the entities in the org.ofbiz.tenant group is the
>>> following: one separate small database is created to host all and only the
>>> org.ofbiz.tenant entities: these entities contain meta-data information for
>>> all tenants (url, db user and password to get access to each tenant db).
>>> The patch you have proposed, by removing the org.ofbiz.tenant group, has
>>> the effect of moving these entities to the main OFBiz database: could you
>>> please check if you see these entities in your local box (with your patch
>>> applied)? Also, could you please check the content of these entities in the
>>> tenant specific databases and in the main database?
>>>
>>>> As far as conditions go, I will elaborate here under what conditions we
>>>> have tested the patch.
>>>>
>>>> We created a virtual test setup consisting of 1 webserver (Apache HTTP)
>>> and
>>>> 1 app server (consisting of Apache OFBiz, set up against derby) whereby
>>> the
>>>> connection and traffic between the 2 servers was with and through the AJP
>>>> protocol.
>>>>
>>>> In that setup we created 5 tenants (with ./ant create-tenant).
>>>> And without the patch we tested all tenants accessing various apps and
>>>> components with Apache JMeter (and scripts). This included accessing
>>>> various functions in webtools as well.
>>> Are you saying that when you log in into Webtools with a tenantId you
>>> actually see the data from the main database rather than the data from the
>>> tenant specific db only? Is this happening for all the entities or just (as
>>> I suspect) for the entities in the org.ofbiz.tenant group?
>>>
>>> Jacopo
>>>
>>>> Subsequently, we implemented the patch and ran the same tests again.
>>> Again
>>>> we had no problems accessing the various apps and components. The only
>>>> thing we didn't succeed in was accessing Tenant and TenantDataSource,
>>> when
>>>> being logged in as a tenant super-user.
>>>> However, when logged in as the admin of the master (without tenantId) we
>>>> were abel to access those entities and its data.
>>>>
>>>> Both situations, being able to access the two entities and the data when
>>>> logged in as master admin and not being able to when logged in as a
>>>> tenant-admin, are as to be expected.
>>>>
>>>> Now, I don't know what that means when having set up the domain name for
>>> a
>>>> tenant as the means to access the tenant environment. Apparently that has
>>>> been developed to have a unique uri per tenant. But we never have had any
>>>> use for that as we in our 3-tier productions setups have it as described
>>> as
>>>> above. This avoids us having to set up internal dns records to point to
>>>> specific tenants to connect to the app server.
>>>>
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>
>
Re: Planning the next releases
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Jacopo,
I just spotted something I want to put in 13.07. It's about demos and stopping and instance launched with a portoffset value.
I want to adapt status and stop ant targets. To pass them a portoffset to allow knowing the instance status or stopping it...
I should do that soon...
Thanks
Jacques
Le 01/03/2014 00:38, Pierre Smits a écrit :
> Jacopo,
>
> Jou said:
>
> the main design around the entities in the org.ofbiz.tenant group is the
> following: one separate small database is created to host all and only the
> org.ofbiz.tenant entities: these entities contain meta-data information for
> all tenants (url, db user and password to get access to each tenant db).
>
>
> That is what I am saying. The database containing the details about each
> tenant should only be accessible from the master, and not from each tenant.
>
> Without the patch the super user of any tenant can see the details (of
> every other tenant) in the tables tenant and tenantdatasource of that
> database. And this shouldn't be.
>
> The patch will ensure that only through the master the db and these tables
> are accessible.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
> On Fri, Feb 28, 2014 at 5:10 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxmedia.com> wrote:
>
>> I have spent some time reviewing a part of the code and I have a few
>> comments inline:
>>
>> On Feb 25, 2014, at 10:48 PM, Pierre Smits <pi...@gmail.com> wrote:
>>
>>> Jacopo,
>>>
>>> I also would like to understand what that means. And what I don't
>>> understand I can't recreate it also.
>> the main design around the entities in the org.ofbiz.tenant group is the
>> following: one separate small database is created to host all and only the
>> org.ofbiz.tenant entities: these entities contain meta-data information for
>> all tenants (url, db user and password to get access to each tenant db).
>> The patch you have proposed, by removing the org.ofbiz.tenant group, has
>> the effect of moving these entities to the main OFBiz database: could you
>> please check if you see these entities in your local box (with your patch
>> applied)? Also, could you please check the content of these entities in the
>> tenant specific databases and in the main database?
>>
>>> As far as conditions go, I will elaborate here under what conditions we
>>> have tested the patch.
>>>
>>> We created a virtual test setup consisting of 1 webserver (Apache HTTP)
>> and
>>> 1 app server (consisting of Apache OFBiz, set up against derby) whereby
>> the
>>> connection and traffic between the 2 servers was with and through the AJP
>>> protocol.
>>>
>>> In that setup we created 5 tenants (with ./ant create-tenant).
>>> And without the patch we tested all tenants accessing various apps and
>>> components with Apache JMeter (and scripts). This included accessing
>>> various functions in webtools as well.
>> Are you saying that when you log in into Webtools with a tenantId you
>> actually see the data from the main database rather than the data from the
>> tenant specific db only? Is this happening for all the entities or just (as
>> I suspect) for the entities in the org.ofbiz.tenant group?
>>
>> Jacopo
>>
>>> Subsequently, we implemented the patch and ran the same tests again.
>> Again
>>> we had no problems accessing the various apps and components. The only
>>> thing we didn't succeed in was accessing Tenant and TenantDataSource,
>> when
>>> being logged in as a tenant super-user.
>>> However, when logged in as the admin of the master (without tenantId) we
>>> were abel to access those entities and its data.
>>>
>>> Both situations, being able to access the two entities and the data when
>>> logged in as master admin and not being able to when logged in as a
>>> tenant-admin, are as to be expected.
>>>
>>> Now, I don't know what that means when having set up the domain name for
>> a
>>> tenant as the means to access the tenant environment. Apparently that has
>>> been developed to have a unique uri per tenant. But we never have had any
>>> use for that as we in our 3-tier productions setups have it as described
>> as
>>> above. This avoids us having to set up internal dns records to point to
>>> specific tenants to connect to the app server.
>>>
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>