On Tue, 19 May 2020 at 19:04, Wasura Wattearachchi <[email protected]> wrote:
> 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? > I get your point. If we consider --update-apis and --update-api-product flags as purely used for determining if existing respective artifacts are going to be updated then we need a 3rd flag for the scenario you are talking about. How about *--import-apis*? If this flag is there we will import both dependent APIs and API Product. If not specified we will only import API Product. So the flag evaluation logic could be something like, if --import-apis == true { // Import the API Product and its dependent APIs } else 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 } else { // Only import the API Product } So the default scenario with no flags only imports the API Product. WDYT? > 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> > > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
