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 <[email protected]> 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. > > - Make it possible to do a test API call without subscribing. > > Not sure if this is required ? > > - Provide Swagger API Console in Publisher as well. > > In publisher shouldn't we invoke the API back-end instead of Gateway ? 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 > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
