[
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444013#comment-13444013
]
Carsten Schinzer edited comment on OFBIZ-5019 at 8/29/12 11:41 PM:
-------------------------------------------------------------------
I have done deeper analysis over the past few days and I think the delegator
identification in the generic ContextFilter needs to be improved.
CURRENT SOLUTION:
=-=-=-=-=-=-=-=-=
If Multitenant use is switched on, delegator in context will be replaced as
follows:
(1) Lookup of TenantId for condition tenant.domain = context.server name
(2) If fail, select default delegator
This is very optimistic as is assumes the following:
* a given tenant would use a single domain only, which might not be true
* a tenant has a related domain defined (this is IMHO not a given even for the
DEMO data)
IMPROVED SOLUTION:
=-=-=-=--=-=-=-=-=
At login to the backend applications, a TenantId is specified during
authentication process. This should be persisted in the session context and and
used to determine the proper delegator through naming convention, namely
default#TENANTID for the delegator name.
I have attempted to follow the 'tenantId' parameter which seems to be put to
context upon login, but this context attribute is lost/not present when the
httpRequest object is being parsed by the ContextFilter of the backoffice apps.
I do not understand what needs to be done to keep this parameter in the context.
Fixes/work required:
- (Re-)Allocate 'tenandId' parameter to session context attributes (not always
present)
- Alter ContextFilter to check on existing delegator name
--> if it has a hash char ('#') and contains tenantId in uppercase after the
char, then leave delegator reference unchanged
--> if not then use the naming convention to fetch the proper delegator from
DelegatorFactory
Could you please comment on this approach before I start implementing?
was (Author: c_schinzer):
I have done deeper analysis over the past few days and I think the
delegator identification in the generic ContextFilter needs to be improved.
CURRENT SOLUTION:
=-=-=-=-=-=-=-=-=
If Multitenant use is switched on, delegator in context will be replaced as
follows:
(1) Lookup of TenantId for condition tenant.domain = context.server name
(2) If fail, select default delegator
This is very optimistic as is assumes the following:
* a given tenant would use a single domain only, which might not be true
* a tenant has a related domain defined (this is IMHO not a given even for the
DEMO data)
IMPROVED SOLUTION:
At login to the backend applications, a TenantId is specified during
authentication process. This should be persisted in the session context and and
used to determine the proper delegator through naming convention, namely
default#TENANTID for the delegator name.
I have attempted to follow the 'tenantId' parameters which seems to be put to
context upon login, but this context attribute ios lost when the httpRequest
object is being parsed by the ContextFilter of the backoffice apps. I do not
understand what to do to keep this parameter in the context.
Fixes/work required:
- (Re-)Allocate 'tenandId' parameter to session context attributes (not always
present)
- Alter ContextFilter to check on existing delegator name
--> if it has a hash char ('#') and contains tenantId after the char, then
leave delegaotr unchanged
--> if not then use the naming convention to lookup the delegator name
Could you please comment on this approach before I start implementing?
> Multitenant delegator assignment not working correctly
> -------------------------------------------------------
>
> Key: OFBIZ-5019
> URL: https://issues.apache.org/jira/browse/OFBIZ-5019
> Project: OFBiz
> Issue Type: Bug
> Components: ALL APPLICATIONS, framework
> Affects Versions: SVN trunk
> Environment: multitenantuse = "Y"
> Tenant with no Domain setting or Tenant using different domain for backend
> applications
> Reporter: Carsten Schinzer
> Labels: authentication, context, multitenancy, security
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> This issue arises when Multitenancy is in use. It arises only on backend
> applications (as typically the frontend store applications will use a context
> variable defined in web.xml to determin the delegator to be used (ie. the
> database to use for data lookups etc).
> The issue manifests as follows:
> * the wrong data is read for standard backoffice displays (e.g. orders,
> accounts, etc.); it is the dataa from the default datasource, not the
> tenant´s data source
> * in the backend apps certain functions require authentication (checked
> dynamically) and this will fail when the default delegator is used since the
> tenant's user accounts will differ (if not in name then in password hashes)
> from the default datasource -- this leads to authentication warnings all over
> the place
> * one will not be able to mainpulate data of course, either
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
