On Tue, 19 May 2020 at 11:31, Malintha Amarasinghe <[email protected]> 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. > 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 <[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 > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
