Hi,
Yes, we can use *--import-apis*. This is nearly similar to the flag
*--with-apis* that we thought to use at the beginning.
But I have another doubt to get clarified. If we are using the above flag
to differentiate whether a particular user is allowed to import (by
creating) dependent APIs, then again we can go with the old two (2)
resources (One for import and the other one for export), right?
Also, we can have a scope named apim:api_product_import_export and assigned
it to both of the resources. When a user who has the above scope tries to
import an API Product, if the --import-apis flag is true then that user
will be allowed to import dependent APIs along with the API Product.
I was thinking whether this satisfies our concern about the restriction
that we thought to do using the scopes because any user who has
apim:api_product_import_export scope can still import an API Product either
with the dependent APIs or not, using the flag --import-apis. Does this
accomplish our goal? WDYT?
Thanks,
Wasura
On Tue, May 19, 2020 at 7:49 PM Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:
>
>
> On Tue, 19 May 2020 at 19:04, Wasura Wattearachchi <was...@wso2.com>
> wrote:
>
>> Hi,
>>
>> On Tue, May 19, 2020 at 12:56 PM Uvindra Dias Jayasinha <uvin...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, 19 May 2020 at 11:31, Malintha Amarasinghe <malint...@wso2.com>
>>> wrote:
>>>
>>>> Implementation wise, would it be a hit if we go with option 2?
>>>> 1. The resources seem a bit duplicated.
>>>> 2. It is difficult to find good names for the two resources as they are
>>>> mostly the same.
>>>>
>>>
>>> We could go with, POST import/api-product and *POST* import
>>> */api-product-with-apis* which would make them very clear and different.
>>>
>>>
>>>> 3. Need additional code at the client-side, to switch between APIs
>>>> based on the scopes of the token.
>>>>
>>>
>>> Had an offline chat with Malintha about this as well. I believe we will
>>> need to decide which resource will be called based on the flag that is
>>> provided in the call(--update-apis or --update-api-products). So the apictl
>>> will not need to do any scope validation. Scope validation will occur at
>>> API level as usual.
>>>
>>
>> Here, when we are importing an API Product, should not we decide whether
>> the user is allowed to *create* APIs or not, instead of just only
>> update.
>> For example,
>>
>> - If a user has the permission to create an API, then when importing
>> the API Product, he/she should be allowed to import the dependent APIs as
>> well.
>> - If a user does not have permission to create APIs, he/she only can
>> import the API Product.
>>
>> IMO, I do not think we can handle this from the flags --update-apis or
>> --update-api-product, because initially without doing any update to the API
>> Product or the API, this problem arises whether we should allow the user to
>> *create
>> APIs*.
>>
>> Any thoughts on this?
>>
>
> I get your point. If we consider --update-apis and --update-api-product
> flags as purely used for determining if existing respective artifacts are
> going to be updated then we need a 3rd flag for the scenario you are
> talking about. How about *--import-apis*? If this flag is there we will
> import both dependent APIs and API Product. If not specified we will only
> import API Product. So the flag evaluation logic could be something like,
>
> if --import-apis == true {
> // Import the API Product and its dependent APIs
> } else If --update-apis == true {
> // Update th dependent APIs *AND* the respective API Product
> } else if --update-api-products == true {
> // Only update the respective API Product
> } else {
> // Only import the API Product
> }
>
> So the default scenario with no flags only imports the API Product. WDYT?
>
>
>
>
>> Thanks,
>> Wasura
>>
>>
>>
>>
>>>
>>>> If we use the other way, we'd only need a small check and can do what
>>>> we need with less effort right?
>>>> The way we check scopes is bit deviating from the other resources. But
>>>> it might be a small sacrifice to keep things simple.
>>>> Just my two cents.
>>>>
>>>
>>> Manlintha already mentioned we are manually checking scopes at code
>>> level to validate the API update scenario to ensure that publisher users
>>> cannot update creator only fields of an API(example: endpoint). So it seems
>>> that this might not be a big deal then.
>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>> Anyway seems there is mostly a semantic difference between the 2
>>> solutions. Can we get some feedback from others as well regarding this?
>>>
>>>
>>>> On Tue, May 19, 2020 at 11:09 AM Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, 18 May 2020 at 20:05, Wasura Wattearachchi <was...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> +1 for the suggestion.
>>>>>>
>>>>>> Please consider the below two (2) solutions where the first one is
>>>>>> what @Malintha Amarasinghe <malint...@wso2.com> suggested.
>>>>>>
>>>>>> *Solution 1*
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Add a new scope (apim:api_product_import_export) to the above
>>>>>> resources.
>>>>>> -
>>>>>>
>>>>>> If the user has apim:api_product_import_export scope, he/she can
>>>>>> import/export the API Product. But if the user wants to import the
>>>>>> dependent APIs as well, then he/she should have the
>>>>>> *apim:api_import_export* scope as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Problems:
>>>>>> -
>>>>>>
>>>>>> When importing an API Product, all things happen within the
>>>>>> REST resource call: POST import/api-product. If we want to
>>>>>> check whether the user has apim:api_import_export scope before
>>>>>> implementing
>>>>>> dependent APIs, it should be done at the implementation level which
>>>>>> has not been done before.
>>>>>> -
>>>>>>
>>>>>> Also, checking whether a particular user has a particular
>>>>>> scope is a task to be done at the REST level, not the at the
>>>>>> implementation
>>>>>> level. Conceptually what we are doing is not suitable here.
>>>>>>
>>>>>>
>>>>>> *Solution 2*
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Create three (3) REST APIs.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Two (2) REST API resources for import API Product task.
>>>>>> 1.
>>>>>>
>>>>>> POST import/api-product
>>>>>> -
>>>>>>
>>>>>> This will require apim:api_product_import_export scope.
>>>>>> Users who have this scope can use this resource to
>>>>>> import/update an API
>>>>>> Product.
>>>>>> -
>>>>>>
>>>>>> Independent APIs will not be allowed to be
>>>>>> imported/updated here.
>>>>>> 2.
>>>>>>
>>>>>> POST import/api-product-apis
>>>>>> -
>>>>>>
>>>>>> This will require apim:api_product_import_export and
>>>>>> apim:api_import_export scopes (We can create a new scope
>>>>>> that incorporates both of these scopes). Users who have this
>>>>>> scope can use
>>>>>> this resource to import/update an API Product and also the
>>>>>> dependent APIs.
>>>>>>
>>>>>> *Note:- *
>>>>>>
>>>>>> -
>>>>>>
>>>>>> *The API Controller will check the scopes of the user
>>>>>> who executes the command and will decide which resource to
>>>>>> be invoked. *
>>>>>> -
>>>>>>
>>>>>> *Both these resources will call the same functions
>>>>>> internally, but at the start, a flag (named
>>>>>> isImportAPIsAllowed) will be
>>>>>> passed. It will be false in (i) and true in (ii). Based on
>>>>>> the value of
>>>>>> that flag, we can decide whether to allow importing
>>>>>> dependent APIs or not.*
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>>
>>>>>> One (2) REST API resource for export API Product task. (The
>>>>>> user should only have apim:api_product_import_export scope for
>>>>>> this)
>>>>>>
>>>>>>
>>>>>>
>>>>>> -
>>>>>>
>>>>>> Problems:
>>>>>> -
>>>>>>
>>>>>> Two (2) resources should be added to almost the same task
>>>>>> (importing).
>>>>>> -
>>>>>>
>>>>>> Two (2) new scopes are needed.
>>>>>> -
>>>>>>
>>>>>> Should come up with meaning full names for the resources and
>>>>>> scopes.
>>>>>>
>>>>>>
>>>>>> WDYT? Your feedback is much appreciated.
>>>>>>
>>>>>
>>>>> +1 for solution 2.
>>>>>
>>>>> Even though there is an additional resource being added I still see
>>>>> this as good because we are able to maintain good REST design principles
>>>>> and maintain the consistency of the access control model we have in place.
>>>>> In this way we dont need to implement custom role validation logic
>>>>> internally to see if the caller can import APIs. The actual REST API
>>>>> resources will only be a thin layer as explained, the implementation logic
>>>>> will be reused by both specifying the relevant scenario via the
>>>>> isImportAPIsAllowed flag.
>>>>>
>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Wasura
>>>>>>
>>>>>> On Mon, May 18, 2020 at 12:03 PM Malintha Amarasinghe <
>>>>>> malint...@wso2.com> wrote:
>>>>>>
>>>>>>> We are also allowing API Developers also to use apictl right. API
>>>>>>> creators are not allowed to create API products. So it may not be a good
>>>>>>> idea to have the same api-impot-export for both product and API import?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> On Mon, May 18, 2020 at 11:48 AM Wasura Wattearachchi <
>>>>>>> was...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We currently do not have any specific scopes for products. We have
>>>>>>>> used *apim:api_publish*, *apim:api_view *kind of scopes in API
>>>>>>>> Products as well.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Wasura
>>>>>>>>
>>>>>>>> On Fri, May 15, 2020 at 8:53 PM Bhathiya Jayasekara <
>>>>>>>> bhath...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> What are the product-related scopes we have now?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Bhathiya
>>>>>>>>>
>>>>>>>>> On Fri, May 15, 2020 at 8:24 PM Wasura Wattearachchi <
>>>>>>>>> was...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> During the code review that conducted today (15th May 2020), a
>>>>>>>>>> question arose related to the scope that has been used in the REST
>>>>>>>>>> API
>>>>>>>>>> level. Currently, the below REST APIs have been implemented to
>>>>>>>>>> import and
>>>>>>>>>> export API Products with the scope apim:api_import_export.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> During the import process, each of the dependent API will be
>>>>>>>>>> imported when the */import/api-product* REST API is called.
>>>>>>>>>> Please consider the below scenario which might be a problem here.
>>>>>>>>>>
>>>>>>>>>> Scenario: There can be users who are publishers who should only
>>>>>>>>>> be allowed to create API Products but not APIs. Also, there can be
>>>>>>>>>> users
>>>>>>>>>> who are creators who should only be allowed to create APIs, not API
>>>>>>>>>> Products. Since we are requesting apim:api_import_export scope
>>>>>>>>>> in the above REST API resources, only a user who is both a creator
>>>>>>>>>> and a
>>>>>>>>>> publisher (eg:- admin) can use these 2 REST API resources.
>>>>>>>>>>
>>>>>>>>>> I would like to know whether this is fair when considering CI/CD
>>>>>>>>>> flow and whether there is a practical situation that this problem
>>>>>>>>>> may arise
>>>>>>>>>> like mentioned here. WDYT?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you!
>>>>>>>>>>
>>>>>>>>>> On Fri, May 15, 2020 at 12:04 PM Wasura Wattearachchi <
>>>>>>>>>> was...@wso2.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> If --update-apis == true {
>>>>>>>>>>>> // Update th dependent APIs *AND* the respective API
>>>>>>>>>>>> Product
>>>>>>>>>>>> } else if --update-api-products == true {
>>>>>>>>>>>> // Only update the respective API Product
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> So higher precedence is given to --update-apis=true and it by
>>>>>>>>>>>> default results in updating the API Product as well(This prevents
>>>>>>>>>>>> Products
>>>>>>>>>>>> from becoming stale if the user changes a API resource's scope but
>>>>>>>>>>>> forgets
>>>>>>>>>>>> to specify that they want to update the API Product to get that
>>>>>>>>>>>> change).
>>>>>>>>>>>> Only --update-apis=true is not specified will we process
>>>>>>>>>>>> --update-api-products=true to only update the Product.
>>>>>>>>>>>>
>>>>>>>>>>>> +1 for the suggestion.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please find the updated scenarios below changed according to the
>>>>>>>>>>> suggestion above. I added 3 more scenarios with
>>>>>>>>>>> --preserve-provider=false
>>>>>>>>>>> to incorporate cross tenant API Product imports.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Scenario
>>>>>>>>>>>
>>>>>>>>>>> --update-api-products
>>>>>>>>>>>
>>>>>>>>>>> --update-apis
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Import a fresh API Product with a fresh set of dependent
>>>>>>>>>>> APIs.
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Import a fresh API Product when dependent APIs are already
>>>>>>>>>>> imported to APIM successfully and you do not want to update
>>>>>>>>>>> those APIs.
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Import a fresh API Product when dependent APIs are already
>>>>>>>>>>> imported to APIM successfully and you want to update those
>>>>>>>>>>> APIs.
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Update the API Product only by changing the meta information
>>>>>>>>>>> and by adding/removing the resources of the API Product.
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Update the API Product by adding new resources to both the
>>>>>>>>>>> API Product and the API(s).
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Update only the dependent APIs.
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Import the API Product and its dependent APIs to another
>>>>>>>>>>> tenant (with --preserve-provider=false)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Update only an already imported API Product and its
>>>>>>>>>>> dependent APIs in another tenant (with
>>>>>>>>>>> --preserve-provider=false)
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> -
>>>>>>>>>>>
>>>>>>>>>>> Update an already imported API Product and its dependent
>>>>>>>>>>> APIs in another tenant (with --preserve-provider=false)
>>>>>>>>>>>
>>>>>>>>>>> Not set (by default false)
>>>>>>>>>>>
>>>>>>>>>>> Set (it will be true)
>>>>>>>>>>>
>>>>>>>>>>> Thank you!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>>>>>>>>>>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>>>>>>>>>>> <https://medium.com/@wasuradananjith>
>>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>>>>>>>>>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>>>>>>>>>> <https://medium.com/@wasuradananjith>
>>>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Bhathiya Jayasekara* | Senior Technical Lead | WSO2 Inc.
>>>>>>>>> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>>>>>>>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>>>>>>>> <https://medium.com/@wasuradananjith>
>>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Malintha Amarasinghe
>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>> http://wso2.com/
>>>>>>>
>>>>>>> Mobile : +94 712383306
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>>>>>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>>>>>> <https://medium.com/@wasuradananjith>
>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Uvindra
>>>>>
>>>>> Mobile: 777733962
>>>>>
>>>>
>>>>
>>>> --
>>>> Malintha Amarasinghe
>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>> http://wso2.com/
>>>>
>>>> Mobile : +94 712383306
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 777733962
>>>
>>
>>
>> --
>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
>> (m) +94775396038 | (e) was...@wso2.com | (b) Medium
>> <https://medium.com/@wasuradananjith>
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>>
>>
>
> --
> Regards,
> Uvindra
>
> Mobile: 777733962
>
--
*Wasura Wattearachchi* | Software Engineer | WSO2 Inc.
(m) +94775396038 | (e) was...@wso2.com | (b) Medium
<https://medium.com/@wasuradananjith>
[image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
