Hi all, Sure, will consider the option stated by @Fazlan Nazeem <[email protected]> for Step 2. Thanks for your opinion.
Adding to the first email, a correction should be made in Step 1 -> Solution 1 as below. (The corrected changes are in bold.) Solution 1 There is an existing resource in Admin v1 as GET /applications which has the ability to “Retrieve a list of all applications of a certain subscriber (but cannot consider the application name)”. The name of the subscriber can be passed to this as a parameter specified by “user=”. We can enhance this further by providing the ability to pass the application name as “appName=” as a new optional parameter. WDYT? Sorry for the inconvenience caused. Thank you! Wasura On Mon, Jul 6, 2020 at 4:58 PM Fazlan Nazeem <[email protected]> wrote: > Hi Wasura, > > There should be an Admin REST API for changing the owner of an > application. In that case, using that to first change the owner and then > deleting is also an option. Please check for any drawbacks. > > On Mon, Jul 6, 2020 at 4:40 PM Wasura Wattearachchi <[email protected]> > wrote: > >> Hi all, >> >> Currently, the API Controller provides “apictl delete app” command which >> consists of the below flags [1]. >> >> Flags: >> >> -e, --environment string Environment from which the Application >> should be deleted >> >> -h, --help help for app >> >> -n, --name string Name of the Application to be deleted >> >> -o, --owner string Owner of the Application to be deleted >> >> In this mail, we will be focussing on the functionality of the -o >> (--owner) flag. The expected functionality of this flag is to allow a >> user (assume User A) to provide the facility to delete an application >> created by another user (assume User B) who is in the same tenant. But, >> the current REST APIs do not provide adequate support for this >> functionality [2]. >> >> Deleting an application consists of two (2) main steps and for those two >> (2) steps, two (2) REST API resources are being used currently, which have >> some drawbacks when it comes to fulfilling the functionality expected from >> the -o (--owner) flag. >> >> >> Step >> >> REST API >> >> Drawback >> >> Solution(s) >> >> 1. Retrieving the applicationId based on the application name (-n/--name >> flag) and the owner’s name (-o/--owner flag) >> >> Store v1 GET /applications >> >> This resource only provides the facility to retrieve an application by >> querying using the application name. Support to query by the owner’s >> name is not provided here. We need the functionality to query by both >> the application name and the owner’s name. But, searching by anyone >> else’s name is not suitable to have in Store REST API. Thus proves that we >> need to have another REST API resource that has the expected functionality >> which can be defined in Admin v1. >> >> Solution 1 >> >> There is an existing resource in Admin v1 as GET /applications which has >> the ability to “Retrieve a list of all applications of a certain subscriber >> (but not the owner)”. The name of the subscriber can be passed to this as a >> parameter specified by “user=”. We can enhance this further by providing >> the ability to pass the owner’s name as “owner=” as a new optional >> parameter. WDYT? >> >> Solution 2 >> >> Define a new REST API resource in Admin v1 without changing any existing >> resources as mentioned in Solution 1. WDYT? >> >> 2. Deleting the application specified by the applicationId. >> >> Store v1 DELETE /applications/{applicationid} >> >> This resource does not allow us to delete applications that belong to >> other users. It provides an output as >> >> {"code":403,"message":"Forbidden","description":"You don't have >> permission to access the application with Id >> <aaplicationId>","moreInfo":"","error":[]} >> >> when we try to delete anyone else’s application. >> >> Solution >> >> Define a new REST API resource that allows deleting applications belong >> to other users who are in the same tenant. WDYT? >> >> >> >> It would be much appreciated if you can share your thoughts when deciding >> the solutions to the above two (2) steps. Please feel free to include any >> new/additional solutions if you have any. >> >> [1] >> https://apim.docs.wso2.com/en/next/learn/api-controller/getting-started-with-wso2-api-controller/#delete-an-apiapi-productapplication-in-an-environment >> >> [2] https://github.com/wso2/product-apim-tooling/issues/335 >> >> 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> >> >> >> > > -- > Thanks & Regards, > > *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc > Mobile : +94772338839 | [email protected] > > > -- *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
