Hi Nuwan, the fact that most of our customers are not using multi-tenancy is a convincing argument :-)
However, let me point out that (vendor-specific) header fields have a bunch of problems. For example, a cache will have to be aware that it has to pass the X-xyz header back to the origin server in case of freshness validation (which is what a cache doesn't do out of the box). Also, a load balancer can't be set up to route requests based on the URL (as in the case the tenantID would be part of the URL), etc. Thus, the REST recommendation is to have tenantIDs in the URL - we need to have arguments available if we are confronted with these weaknesses in a review. Finally a question: How do we identify tenants in C5? Or don't we support multi-tenancy in C5? Best regards, Frank 2015-11-23 5:26 GMT+01:00 Nuwan Dias <nuw...@wso2.com>: > Hi Frank, > > In Summary, there are two main reasons we decided to go against having the > tenant domain as part of the URI. > > 1. Its optional. For people who aren't interested in multi-tenancy ( > > 75%), there would not be a need to expose this complexity. > > 2. With C5, tenancy is going to be container based. Therefore the > underlying Applications would not (necessarily) have to deal with tenant > related concepts. So having a tenant domain as part of the URL would not > make much sense in there. > > Thanks, > NuwanD. > > On Sun, Nov 22, 2015 at 11:18 PM, Malintha Amarasinghe <malint...@wso2.com > > wrote: > >> Hi, >> >> Yes we have implemented it in the way Sanjeewa mentioned in the previous >> mail. Due to the complexity and inconsistency (with the requests which does >> not require tenant domain) of having the tenant domain as the part of the >> context, we decided to send it as a query/header parameter. According to >> the current implementation, we have used a header parameter. >> >> A sample request would be as follow: >> >> >> - User "us...@wso2.com" wants to see what are the APIs that are >> available in the tenant cloud.com >> >> *GET* http://127.0.0.1:9764/api/am/store/v1/apis HTTP/1.1 >> *X-WSO2-Tenant*: cloud.com >> *Authorization*: *Basic* *Or Bearer token* >> >> >> >> We identify the user's tenant domain from the authorization header. If he >> need to lookup resources of a different tenant domain, he can send it from >> the *X-WSO2-Tenant *header. This is only supported in Store for >> following use cases. >> >> 1. User wants to get all APIs from a different tenant domain. >> 2. User wants to get a specific API from a different tenant domain. >> 3. User wants to see documents of an API which is in a different tenant >> domain. >> 4, User wants to see a specific document of an API which is in a >> different tenant domain. >> >> Thank you. >> Malintha. >> >> >> >> On Sun, Nov 22, 2015 at 9:49 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >> wrote: >> >>> Hi frank, >>> As we discussed during last meeting tenant domain will not be a part of >>> context. So application url remain as it is and current logged tenant will >>> identified using authentication details client send(we start tenant flow >>> based on logged in user). >>> If need we can make tenant name query parameter in url. >>> Requested tenant can be transport header and part of API. >>> >>> I think malintha already implemented this for some resources which >>> requires requested tenant. He may provide more information. >>> >>> Thanks >>> sanjeewa. >>> >>> sent from my phone >>> On Nov 22, 2015 7:14 PM, "Frank Leymann" <fr...@wso2.com> wrote: >>> >>>> Dear all, >>>> >>>> let me try to understand: >>>> >>>> A user (us...@wso2.com) wants to access a resource created by a >>>> certain tenant (cloud.com) - correct? The tenant created the resource >>>> and we decided to make the tenant-id part of the context of the resource's >>>> URL. >>>> >>>> Thus, the user who wants to access the tenant's resource is a parameter >>>> of some sort of (new?) API that requests access to the tenant's resource. >>>> >>>> This (new?) API would look something like this: >>>> >>>> <host>/<context>/{tenant}/<API-name>/<parameters>&user=us...@wso2.com >>>> >>>> Does it make sense or did I miss the discussion? >>>> >>>> >>>> >>>> Best regards, >>>> Frank >>>> >>>> 2015-11-17 16:16 GMT+01:00 Sanjeewa Malalgoda <sanje...@wso2.com>: >>>> >>>>> 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 < >>>>> malint...@wso2.com> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> In API Manager REST API, we will be supporting cross tenant >>>>>> scenarios. Few examples would be like below. >>>>>> >>>>>> 1. us...@wso2.com wants to see the APIs that are available in the >>>>>> tenant store; cloud.com >>>>>> 2. us...@wso2.com 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/> >>>>> >>>>> >>>>> >>>> >> >> >> -- >> Malintha Amarasinghe >> Software Engineer >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> > > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
