[
https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511502#comment-13511502
]
Carsten Schinzer commented on OFBIZ-5019:
-----------------------------------------
This does still not work properly in my local environment. What I have done so
far:
The adapted ContextFilter will ensure:
- new delegator is created when multitenant use is configured and tenantId is
in the HttpRequest
- new delegator is created when multitenant use is configured and tenantId in
HttpRequest does not match in the delegatorName (ie. current delegator is for a
different tenant)
- attempt to create proper delegator for the first tenant in the list of
tenants when no information is present in HttpRequest
I can also see that LoginWorker attempts to redefine the delegator (again?),
but the ContextFilter should already have done that work. Anyone with a comment
regarding this additional delegator fiddling? Is there any situation where
LoginWorker is called and ContextFilter no being invoked beforehand?
Thanks for your comments.
Regards
Carsten
> 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
> Attachments:
> OFBIZ-5019_Multitenant_delegator_assignment_not_working_correctly.patch
>
> 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
