|
[ https://issues.apache.org/jira/browse/OFBIZ-5019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13527505#comment-13527505 ] Carsten Schinzer commented on OFBIZ-5019: ----------------------------------------- I would like to understand what the requirements are for the ContextFilter to place delegatorName in the various contexts. From what I read in code, this is where delegator information is placed in Contexts:: ServletContext - delegator (e.g. definiton in web.xml - dispatcher SessionContext: - delegator - delegatorName - dispatcher Before I move on with this fix, I need to understand whether the following assumption is correct: The ServletContext exists for the Servlet, not per instance. Write operations to it should thus be avoided in order to prevent inconsistencies. However, for Multitenant delegator, this occurs in current code. The SessionContext exists for each Session and can thus contain Session-dependant items, such as Multitenant tenantId, delegator and dispatcher (and many more of course) Based in these assumptions, I shall fix the Multitenant-part in the ContextFilter as follows: (1) check if ServletContext has a Multitenant-delegator -- if so: copy into Session Context, bail out -- else: (2) check if SessionContext has a Multitenant-delegator for the current tenantId -- if so: the work is done, bail out -- else: (3) check if SessionContext has a tenantId parameter -- if so: create the Multitenant-delegator using baseDelegatorName from ServletContext + "#" + tenantId -- else: re-use existing code (but that is weak and should rather become an Exception case) In order for this to run, I need confirmation that any invocation of a delegator will first check for a delegator in the SessionContext before falling back to the delegator in the ServletContext. Could this assumption be confirmed by someone from the committers? > 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 |
|
All,
I really need help on this -- I know multitenant is not very popular in use. Yet, if someone could find time to look at this, would be a great help! I have modified ContextFilter and LoginWorker now as follows in my local environment: LoginWorker: - identifies the correct tenant delegator and places it in Session Context ContextFilter: - assure the tenant delegator is in SessionContext and places it in the HttpRequest - does no longer overwrite the ServletContext delegator with the tenantDelegator (this is bad practice IMHO) Since this change the logins work perfectly fine however the data I am seeing in backoffice applications are not the tenant data but the data on the main ofbiz instance. So the backoffice application pages seem to be always using the delegator in the ServletContext and not the Visit's or the HttpRequest's or the SessionContext's. Can someone confirm this statement and please point me where in the framework I would change that behaviour? IMHO the current, official implementation on the trunk which overwrites the ServletContext parameter is bad practice and moreover is not robust enough to support concurrent use of apps by different tenants. Thanks for your support! Regards Carsten |
|
As a proof of my srtatement yesterday I have now put the 'evil' line back into ContextFilter that overwrites ServletContext with the delegator AND IT WORKS.
In order to cope with this on Logout, I have changed the LoginWorker.doBasicLogout to re-initialize a Delegator object using the Servlet's initParameter delegatorName. This cannot be called better than a workarounbd for the fact that the backoffice apps are not ready for Multitenant use, at least not for robust, concurrent access to these apps by several tenants. Also, I did a search for 'getAttribute("delegator")' in java files, but all I can see are accesses to the HttpRequest. So my call for help remains: can anyone point me to the basic delegator retrieval mechanism that backoffice apps use? They seem to be reading servletcontext regardless Thanks + regatds Carsten Gesendet mit BlackBerry® Webmail von Telekom Deutschland -----Original Message----- From: Carsten Schinzer <[hidden email]> Date: Thu, 17 Jan 2013 08:23:46 To: <[hidden email]> Subject: Re: [jira] [Commented] (OFBIZ-5019) Multitenant delegator assignment not working correctly All, I really need help on this -- I know multitenant is not very popular in use. Yet, if someone could find time to look at this, would be a great help! I have modified ContextFilter and LoginWorker now as follows in my local environment: LoginWorker: - identifies the correct tenant delegator and places it in Session Context ContextFilter: - assure the tenant delegator is in SessionContext and places it in the HttpRequest - does no longer overwrite the ServletContext delegator with the tenantDelegator (this is bad practice IMHO) Since this change the logins work perfectly fine however the data I am seeing in backoffice applications are not the tenant data but the data on the main ofbiz instance. So the backoffice application pages seem to be always using the delegator in the ServletContext and not the Visit's or the HttpRequest's or the SessionContext's. Can someone confirm this statement and please point me where in the framework I would change that behaviour? IMHO the current, official implementation on the trunk which overwrites the ServletContext parameter is bad practice and moreover is not robust enough to support concurrent use of apps by different tenants. Thanks for your support! Regards Carsten |
| Free forum by Nabble | Edit this page |
