Hi Dushan, If we make it optional, users will use that to create applications and generate keys as they desire, which would again deviate the original purpose. Hence IMO I believe it is enough to limited to a single application as this is only for testing purposes.
Thanks, DinushaD On Wed, Sep 4, 2019 at 10:04 AM Dushan Silva <[email protected]> wrote: > I agree with nuwan on this we do not need to pass the application as it > would defeat the purpose of this feature in the first place. However we can > provide the application name as an *optional* parameter, if the user has > already created an application using the rest api, he can use that name > using the CLI. WDYT? > > On Mon, Sep 2, 2019 at 5:20 PM Nuwan Dias <[email protected]> wrote: > >> I think we should look back at the intention of this command. The two >> main objectives of the key-gen commands are as below. >> >> 1) For someone using the CLI to create, deploy and test APIs without >> leaving the terminal itself. >> 2) For CI/CD tools to be able to perform automated tests before promoting >> APIs to upper environments. >> >> Given the above two objectives, any input required other than the API >> name and version itself would jeopardise the purpose of this command. A >> CI/CD tool will anyway not be able to provide an application name, so >> that's out of the question I guess. If a human being who wants to test the >> API is requested to input the App name, that means that person has to login >> to the store and have awareness about an application, subscription, etc. If >> that person has access to the store, why would he/she need to generate keys >> from the CLI itself? The store already provides a key and also a cURL >> command to get a key using any preferred grant type anyway. So if we assume >> a person has to login to the store first to create or get info about an >> existing app, I see no further use of him/her to be using the key-gen >> command on the CLI. >> >> Thanks, >> NuwanD. >> >> On Mon, Sep 2, 2019 at 3:41 PM Chamila Adhikarinayake <[email protected]> >> wrote: >> >>> Hi Pubudu, >>> Any reason for subscribing to the default application? I think we should >>> pass the application name as a parameter instead of subscribing to a >>> default application. >>> >>> On Mon, Sep 2, 2019 at 12:19 PM Pubudu Gunatilaka <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> With the latest improvements to the APIMCLI, users are able to publish >>>> the API in published state and it allows Store users to discover the API in >>>> the developer portal. Basically, to invoke the API, he has to obtain an >>>> access token and has to follow the following approach. >>>> >>>> 1. Log in to the Store >>>> 2. Subscribe to an API >>>> 3. Generate an access token >>>> >>>> For any user, he has to use the above approach or use the REST APIs and >>>> generate the token. >>>> >>>> We have improved the CI/CD pipeline approach with APIMCLI and we can >>>> further enhance this by allowing APIMCLI to generate an access token. So >>>> the CI/CD pipeline can be improved to run a test suite with the generated >>>> access token from the APIMCLI. >>>> >>>> Suggested CLI command: >>>> >>>> *apimcli get keys -n TwitterAPI -v 1.0.0 -e dev --provider admin* >>>> >>>> This command does the following. >>>> >>>> 1. Subscribe the given API to the Default Application if it not already >>>> subscribed. >>>> 2. Generate an access token. >>>> >>>> Output: *JWT token* >>>> >>>> From the next release onwards, we will be having self-contained access >>>> tokens (JWT) for the default application as it will be the first option. >>>> >>>> Your suggestions are appreciated. >>>> >>>> Thank you! >>>> -- >>>> *Pubudu Gunatilaka* | Associate Technical Lead | WSO2 Inc. >>>> (m) +94774078049 | (w) +94112145345 | (e) [email protected] >>>> <http://wso2.com/signature> >>>> >>>> >>> >>> -- >>> Regards, >>> Chamila Adhikarinayake >>> Associate Technical Lead >>> WSO2, Inc. >>> Mobile - +94712346437 >>> Email - [email protected] >>> Blog - http://helpfromadhi.blogspot.com/ >>> >> >> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) [email protected] >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Best Regards > Dushan Silva > Software Engineer > > *WSO2, Inc. * > > lean . enterprise . middleware > Mob: +94 774 979042 > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Dinusha Dissanayake* | Senior Software Engineer | WSO2 Inc (m) +94 71 293 9439 | (e) [email protected] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
