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. 3. Need additional code at the client-side, to switch between APIs based on the scopes of the token.
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. Thanks! On Tue, May 19, 2020 at 11:09 AM Uvindra Dias Jayasinha <[email protected]> wrote: > > > On Mon, 18 May 2020 at 20:05, Wasura Wattearachchi <[email protected]> > wrote: > >> 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. >> > > +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 <[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> >> >> >> > > -- > Regards, > Uvindra > > Mobile: 777733962 > -- 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
