Hi, On Tue, May 19, 2020 at 12:56 PM Uvindra Dias Jayasinha <[email protected]> wrote:
> > > 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. > 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? 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 <[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 > -- *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
