It should be fine. What happen if API resources protect with scopes? May be request all the scopes in the API with the request?
On Thu, Sep 12, 2019 at 11:56 PM Dinusha Dissanayake <[email protected]> wrote: > Hi Harsha, > > We are generating tokens using the client credentials grant type. Since > this is only for testing purposes, we do not need to support multiple grant > types. do we? > > > On Thu, Sep 12, 2019 at 5:51 PM Harsha Kumara <[email protected]> wrote: > >> @Dinusha Dissanayake <[email protected]> Are we generating a client >> credentials token or pass grant type based token? >> >> On Wed, Sep 4, 2019 at 10:31 AM Dinusha Dissanayake <[email protected]> >> wrote: >> >>> 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 >>> >> >> >> -- >> >> *Harsha Kumara* >> >> Technical Lead, WSO2 Inc. >> Mobile: +94775505618 >> Email: [email protected] >> Blog: harshcreationz.blogspot.com >> >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > *Dinusha Dissanayake* | Senior Software Engineer | WSO2 Inc > (m) +94 71 293 9439 | (e) [email protected] > > <https://wso2.com/signature> > -- *Harsha Kumara* Technical Lead, WSO2 Inc. Mobile: +94775505618 Email: [email protected] Blog: harshcreationz.blogspot.com GET INTEGRATION AGILE Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
