Hi, +1 for the suggestion.
Please consider the below two (2) solutions where the first one is what @Malintha Amarasinghe <[email protected]> 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. Thanks, Wasura On Mon, May 18, 2020 at 12:03 PM Malintha Amarasinghe <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> What are the product-related scopes we have now? >>> >>> Thanks, >>> Bhathiya >>> >>> On Fri, May 15, 2020 at 8:24 PM Wasura Wattearachchi <[email protected]> >>> 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 <[email protected]> >>>> 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) [email protected] | (b) Medium >>>>> <https://medium.com/@wasuradananjith> >>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> *Wasura Wattearachchi* | Software Engineer | WSO2 Inc. >>>> (m) +94775396038 | (e) [email protected] | (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) [email protected] | (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) [email protected] | (b) Medium <https://medium.com/@wasuradananjith> [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
