Sorry Wasura, what you are talking about is not clear to me, the context is a bit mixed up.
On Tue, 19 May 2020 at 22:19, Wasura Wattearachchi <[email protected]> wrote: > Hi, > > Yes, we can use *--import-apis*. This is nearly similar to the flag > *--with-apis* that we thought to use at the beginning. > > But I have another doubt to get clarified. If we are using the above flag > to differentiate whether a particular user is allowed to import (by > creating) dependent APIs, then again we can go with the old two (2) > resources (One for import and the other one for export), right? > > Also, we can have a scope named apim:api_product_import_export and > assigned it to both of the resources. When a user who has the above scope > tries to import an API Product, if the --import-apis flag is true then > that user will be allowed to import dependent APIs along with the API > Product. > > I was thinking whether this satisfies our concern about the restriction > that we thought to do using the scopes because any user who has > apim:api_product_import_export scope can still import an API Product > either with the dependent APIs or not, using the flag --import-apis. Does > this accomplish our goal? WDYT? > > Thanks, > > Wasura > > On Tue, May 19, 2020 at 7:49 PM Uvindra Dias Jayasinha <[email protected]> > wrote: > >> >> >> 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 >> > > > -- > *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
