Hi Harsha, This is already handled. Once the APIs are subscribed to the application, all the scopes of the APIs subscribed to the application are retrieved. Then scopes will be passed when generating the access token.
Another concern we need to handle is pointing the endpoints to the apimcli tool. Because APIM 3.0.0 is shipped with rest API v0.14 and the v1. Currently, the apimcli tool is compatible with v0.14. Hence I've also carried out the implementation based on v0.14. Thanks, DinushaD On Fri, Sep 13, 2019 at 11:08 AM Harsha Kumara <[email protected]> wrote: > 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 > -- *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
