Re: [Architecture] [API Manager] Improve APIM CLI to generate a token for an API

[Harsha Kumara]

On Sat, Sep 14, 2019 at 10:14 AM Dinusha Dissanayake 
wrote:

> 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.
>
+1 to go with .14 at the moment. We need to release a new major version of
the tool for the APIM V3 version.

>
> Thanks,
> DinushaD
>
> On Fri, Sep 13, 2019 at 11:08 AM Harsha Kumara  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 
>> 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  wrote:
>>>
 @Dinusha Dissanayake  Are we generating a client
 credentials token or pass grant type based token?

 On Wed, Sep 4, 2019 at 10:31 AM Dinusha Dissanayake 
 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  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  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 <
>>> chami...@wso2.com> 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 
 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.

Re: [Architecture] [API Manager] Improve APIM CLI to generate a token for an API

[Dinusha Dissanayake]

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  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 
> 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  wrote:
>>
>>> @Dinusha Dissanayake  Are we generating a client
>>> credentials token or pass grant type based token?
>>>
>>> On Wed, Sep 4, 2019 at 10:31 AM Dinusha Dissanayake 
>>> 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  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  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 <
>> chami...@wso2.com> 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 
>>> 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.

[Architecture] WSO2 API Manager 3.0.0-M35 Released!

[Samitha Chathuranga]

The *WSO2 API Manager team *is pleased to announce the release of *API
Manager 3.0.0-m35*. It's now available to download.

Note: This release mainly includes the bleeding edge versions of the newly
revamped API Manager Publisher and Store. You can try-out the new
applications from below URLs

   - https://localhost:9443/publisher-new
   - https://localhost:9443/store-new

Distribution

   - wso2apim-3.0.0-m35
   


Documentation

   - WSO2 API Manager 3.0.0 

Following list contains all the features, improvements and bug fixes
available with this milestone.
New Feature

   - Product-APIM new features
   


Bug Fixes

   - Product-APIM Bug fixes
   


Improvements

   - Product-APIM improvements
   


List of Open Issues

   - Open Issues for Product-APIM
   


How To Contribute

Your feedback is most welcome!
Mailing Lists

Join our mailing list and collaborate with the developers directly.

Developer List : d...@wso2.org | Subscribe | Mail Archive


   - User Forum : StackOverflow
   

Reporting Issues

We encourage you to report issues, improvements and feature requests
regarding WSO2 API Manager through WSO2 API Manager GIT Issues
.

~ WSO2 API Manager Team ~


-- 
*Samitha Chathuranga*
*Senior Software Engineer*, *WSO2 Inc.*
lean.enterprise.middleware
Mobile: +94715123761

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture