Hi Jo,

On 23 March 2017 at 12:46, Joseph Fonseka <jos...@wso2.com> wrote:

> Hi
>
> Did we look at solving the mention problems / confusions with some UI
> changes / enhancements. Some suggestions are bellow.
>
> On Thu, Mar 23, 2017 at 8:28 AM, Lakmali Baminiwatta <lakm...@wso2.com>
> wrote:
>>
>>
>>    - Ideally the UI application (ex: store) is the real application
>>    which does the test API calls.
>>    - People get it confused with the application tokens we provide in
>>    the store and use those in the real use cases.
>>
>> Move the application token generation to the API console and make it part
> of the API tryout/testing. For the APIs that require subscription we can
> guide the user to subscribe before generating a token to test. Also we can
> give them to test some advanced scenarios like authorization code.
>

This is possible in the Store with swagger provided features + users apps.

>
>>    - Make it possible to do a test API call without subscribing.
>>
>> Not sure if this is required ?
>

For the API publisher this is useful to test the APIs. Even in the store,
allowing some test calls before subscribing to them can be a useful
feature.

>
>>    - Provide Swagger API Console in Publisher as well.
>>
>> In publisher shouldn't we invoke the API back-end instead of Gateway ?
>

I guess publisher may need to test the API execution flow through gateway.
For instance the resource paths, mediation logics, etc.

Thanks,
Lakmali

>
> IMO it would be difficult to explain the mention approach to a user than
> what we have.
>
> Thanks & Regards
> Jo
>
>
>
>> The proposed solution is to generate an access token with the UUF app's
>> credentials + special scope. The subscription validation will be skipped
>> for the tokens in this special scope. For implementing the solution, we
>> have to consider below points.
>>
>>
>>    - Grant Type - If the client_credentials grant type is used, all the
>>    concurrent users accessing the UI app will get the same token. In order to
>>    do any user level restrictions for this token in the gateway level, we 
>> have
>>    to use password grant type. One case is visibility restricted API
>>    invocations. Also I guess we shouldn't allow to invoke API resources
>>    protected with scopes if the logged in user is not allowed for that.
>>
>>
>>    - Scope white listing - This scope has to be white listed, since the
>>    API resource is not actually protected with it.
>>
>>
>>    - Throttling - Since there is no API subscription, special throttle
>>    limit has to be applied with some minimum quota. One option is to apply 
>> the
>>    unauthenticated tier limits which does a throttling based on the client 
>> IP.
>>
>>
>>    - Token validity and refresh token - If the client_credential grant
>>    type is used, we can't invalidate this test token when a user is logged 
>> out
>>    since other users might be using it already. Therefore IMO, we can use
>>    password grant type and use the similar token refreshing mechanism done 
>> for
>>    UUF app authentication.
>>
>>
>>    - Obtaining the access token - In order to get an access token, we
>>    need the consumer key and secret of the UUF app. Currently we do a UUF
>>    backend app call only when the user is authenticating or when refreshing
>>    the token. So here also, I think we can generate the test token when the
>>    user is authenticated(log in to the UUF app) and store it in the local
>>    storage. I believe its okay to display this access token for the user.
>>
>> Thoughts?
>>
>> Thanks,
>> Lakmali
>>
>>
>> --
>> Lakmali Baminiwatta
>> Associate Technical Lead
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile:  +94 71 2335936
>> blog : lakmali.com
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Lakmali Baminiwatta
Associate Technical Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile:  +94 71 2335936
blog : lakmali.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to