You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Carsten Schinzer (JIRA)" <ji...@apache.org> on 2012/08/29 14:42:08 UTC
[jira] [Comment Edited] (OFBIZ-5019) Multitenant delegator
assignment not working correctly
[ 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