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/>
>
>
>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
