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