I added thread local variable to our component to keep track of requested tenant as we cannot use carbon context. We will set requested tenant in CXF interceptor level and reuse it in other places. After initial tests will merge this to rest API component.
Thanks, sanjeewa. On Tue, Nov 17, 2015 at 8:46 PM, Sanjeewa Malalgoda <[email protected]> wrote: > If we think this very carefully requested tenant domain should be part of > the API. > Let me explain it, > We have API and that behave in some manner according to provided > parameters and inputs. > In this particular scenario, we are passing completely different data set > and get different results. > So cant we take this as user input for API? If we added that as parameter > then it will be part of API(non mandatory parameter). > > Or else we may need to have ability of setting custom fields in carbon > context as that can be accessible across all places of started flow. > But according to current implementation we cannot place anything in carbon > context. > With tenant app sharing concept we need to have logged in tenant and > requested tenant both in message context to give proper results. > Shouldn't we have that capability in carbon context? > > Thanks, > sanjeewa. > > > > On Mon, Nov 16, 2015 at 2:20 PM, Malintha Amarasinghe <[email protected]> > wrote: > >> Hi All, >> >> In API Manager REST API, we will be supporting cross tenant scenarios. >> Few examples would be like below. >> >> 1. [email protected] wants to see the APIs that are available in the tenant >> store; cloud.com >> 2. [email protected] wants to see the documents of an API weatherAPI that >> are available in the tenant store; cloud.com >> >> For this requirement we need to pass the "required tenant domain" >> parameter with the request as the logged in user belongs to is a different >> tenant. There are several possible ways to specify this. >> >> 1. Specify this as a query parameter for every resource this is required >> >> ex: GET >> http://127.0.0.1:9763/api/am/publisher/v1/apis?*tenantDomain=cloud.com >> <http://cloud.com>* >> >> >> 2. Specify this as a header parameter >> >> 3. Specify this within the URI. >> >> a. before the Jax-RS web app context >> >> ex: GET http://127.0.0.1:9763/*t/cloud.com <http://cloud.com>* >> /api/am/publisher/v1/apis >> >> b. after the Jax-RS web app context >> >> ex: GET http://127.0.0.1:9763/api/am/publisher/v1/*t/cloud.com >> <http://cloud.com>*/apis >> >> >> Regarding these three options, option (3.a) would require the web app to >> be deployed on each and every tenant. Or otherwise we should manually >> register contexts in tomcat run-time to match those contexts. Even if we >> register context manually, this would not be a good solution as the user >> might expect the web app to be in the tenant space (when he sees the >> /t/tenant part in the URI) but it is not there actually. Option (3.b) would >> require the web app to handle the tenant as a resource and every other >> resource would need to be a sub-resource. And we need to specifically >> handle for the super tenant which we don't specify the tenant in the URL. >> For options (1) and (2), we don't need to face such difficulties. >> >> Please share your thoughts. >> >> Thanks. >> Malintha >> >> -- >> Malintha Amarasinghe >> Software Engineer >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> > > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
