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