Re: [Architecture] [APIM][C5] API Editor Application
On 17 May 2017 at 12:05, Rajith Roshan <raji...@wso2.com> wrote: > Hi, > > > On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma <thar...@wso2.com> > wrote: > >> Hi all, >> >> In API Manager, we will be exposing an application called the API >> Editor which is basically a subset of the API Publisher. The Editor >> application is *run locally* in the API developers machine and is used >> primarily for API *testing purposes*. >> >> What can be done through the Editor Application? >> >> >>- APIs will be created and stored in the local file system. >> >> The file structure of the created API will be, >> >> [image: Inline image 1] >> >> where *--* is the folder >> in which the configuration files for the API are stored. The Endpoints >> folder contains the api level endpoints for the API. >> >>- API level endpoints are used instead of global endpoints. >>- After creating and testing an API from within the API Editor, the >>API developer can export the API to the Publisher. >>- It supports API import and export. >> >> Is it necessary to support import feature on the editor. Is there a valid > use case to import apis into editor. > When the developers want to later change the already exported APIs and also to share the API development through source controlling, importing feature is required. Thanks, Lakmali > >>- >>- The API can be exported as a zip file and it contains the above >>file structure. >> >> Appreciate your thoughts and concerns. >> >> Thanks, >> Tharika. >> >> -- >> *Tharika Madurapperuma* >> Software Engineer | WSO2, Inc. >> >> Email : thar...@wso2.com >> Mobile : +94777875624 <+94%2077%20787%205624> >> Web : http://wso2.com >> >> <http://wso2.com/signature> >> > > > > -- > Rajith Roshan > Software Engineer, WSO2 Inc. > Mobile: +94-7 <%2B94-71-554-8430>17-064-214 > > ___ > 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
Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.
On 15 May 2017 at 14:41, Nuwan Dias <nuw...@wso2.com> wrote: > What is the benefit of using operationId instead of the resource path? In > the current Swagger we do not have operationIds defined right? > Since it will be just a string, it is less error prone than defining the resource path and also even when the resource path is changed in a major release, we can keep the operationId unchanged. Yeah, we don't have them defined right now. If we introduce operationIds just for this use case, as developers we need > to spend time thinking of operationIds per resource, make sure we don't > duplicate operationIds and more importantly never change operationIds in > newer versions :). > Through swagger validation we can ensure is is not duplicated. However, as you said we don't have a way to ensure no one changes them in new releases. To me at least something in the form of [http_method] [path] [scope], ex: > POST /apis foo, is more natural than artificially built operationIds. So > unless there's a huge benefit in using operationIds vs resource paths, I > think we should just stick to the resource paths. > If we use operationIds, they should be self descriptive and not just unique strings. However, I am ok with the resource path. It is just that I think defining operationId will be more easier for the users. > > Regarding scope to role mapping, that is only required for the Key Manager > (IS). Since it is the KM who issues and validates tokens, this mapping is > only required by the KM AFAIU. > > On Thu, May 11, 2017 at 3:14 PM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> If we are to avoid migration of modified scopes, I think we have to go >> with the second approach of defining resource to scope mapping in an >> optional config file. However, rather than defining the resource path in >> this file, how about using an unique identifier per operation? In swagger, >> we can define an *operationId* per operation which must be unique >> [1][2]. This way even if a resource path changes in a major release, >> *operationId >> *won't change*. * >> >> BTW we also have to allow configuring scope to role mapping. >> >> [1] http://swagger.io/specification/ >> [2] http://petstore.swagger.io/v2/swagger.json >> >> Thanks, >> Lakmali >> >> On 10 May 2017 at 11:26, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> So it seems Sanjeewa's and my view points are clear on this. >>> >>> 1. Sanjeewa basically says let users (sys-admins) edit the Swagger file >>> that define the product REST API. Objective is to avoid duplicating >>> resource to scope mappings elsewhere. >>> >>> 2. I basically say maintain an optional config file so that users >>> (sys-admins) can declare the resource to scope mappings they "want to >>> override only" in that file. Objective is to separate user configs from >>> product configs to minmize risk in someone playing with the product API. >>> >>> The pros and cons of each approach have been discussed throughly. So we >>> basically need more ideas from others now. Either better solutions or a >>> preference towards one of the suggested ones. >>> >>> On Wed, May 10, 2017 at 11:20 AM, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> No Sanjeewa, in the method I'm proposing the system "will not break" >>>> even if someone goes and puts Japanese characters in the config file. That >>>> is by design. >>>> >>>> One design principle from 3.0.0 onwards is to have no migration script >>>> involved. In the method I'm proposing we avoid migration 100% (for this >>>> part). I personally think that is a huge gain. >>>> >>>> On Tue, May 9, 2017 at 8:52 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tue, May 9, 2017 at 4:57 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>> >>>>>> Regarding adding entries to the config file, you don't need to even >>>>>> open the swagger file. What you need to do is to find the resource from >>>>>> the >>>>>> docs and enter it into the config file. By expecting a sys admin to edit >>>>>> the Swagger file my main worry is we're expecting the sys-admin to play >>>>>> with an extremely critical file in the system and expecting him to behave >>>>>> well (no funky mistakes). If he or an automation tool does 1 silly >>>>>> mistake, >>>>>&
Re: [Architecture] {APIM 3.0.0} Allowing admin user to customize Product REST APIs.
gt;>>>>>>>> to determine by system administrator by the time deployment >>>>>>>>>>>> initialize and >>>>>>>>>>>> should update only when required. Ex if you allow to update some >>>>>>>>>>>> resource >>>>>>>>>>>> to given role and randomly revoke that its not nice. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, by "user" I actually meant sys-admin. The guy configuring >>>>>>>>>>> the server actually. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> What if we allow the default resource to scope mapping remain >>>>>>>>>>>>> in the Swagger doc and introduce a new config file to override >>>>>>>>>>>>> whatever >>>>>>>>>>>>> resource to scope mappings a user needs? To determine the scope >>>>>>>>>>>>> of a >>>>>>>>>>>>> particular resource our code should first be checking the >>>>>>>>>>>>> custom/optional >>>>>>>>>>>>> config file and if an entry for the particular resource doesn't >>>>>>>>>>>>> exist, then >>>>>>>>>>>>> default to the Swagger file. >>>>>>>>>>>>> >>>>>>>>>>>> Having more config files will make things complicate IMO. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If we copy the Swagger to the conf directory, that becomes a >>>>>>>>>>> duplicate config file anyway (one in the jar and one outside the >>>>>>>>>>> jar). And >>>>>>>>>>> when we do that we grant full access to the sys-admin to play with >>>>>>>>>>> the >>>>>>>>>>> product rest API (the full Swagger doc). Which is not needed. What >>>>>>>>>>> he only >>>>>>>>>>> needs is to override the resource to scope mapping. Which I think >>>>>>>>>>> should be >>>>>>>>>>> possible to provide by having a optional place to override whatever >>>>>>>>>>> mapping >>>>>>>>>>> he needs only. >>>>>>>>>>> >>>>>>>>>>> We also need to think about product upgrades. If the sys admin >>>>>>>>>>> edits the swagger of one version and then upgrades the server, >>>>>>>>>>> he'll be >>>>>>>>>>> expected to merge whatever his changes with the newer swagger doc >>>>>>>>>>> of the >>>>>>>>>>> product. Which can be troublesome. But if we use an optional config >>>>>>>>>>> that >>>>>>>>>>> only overrides whatever resources he wants, he can simply use the >>>>>>>>>>> same file >>>>>>>>>>> on the new version of the product. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> sanjeewa. >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This way the optional config file only needs to bear the >>>>>>>>>>>>> resource to scope mappings that need to be overridden in a >>>>>>>>>>>>> particular >>>>>>>>>>>>> deployment and hence won't be that long. It also ensures that >>>>>>>>>>>>> during >>>>>>>>>>>>> product upgrades users don't have to meddle with the current >>>>>>>>>>>>> config file >>>>>>>>>>>>> and can keep using it on newer versions too. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> NuwanD. >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, May 8, 2017 at 11:46 PM, Sanjeewa Malalgoda < >>>>>>>>>>>>> sanje...@wso2.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:42 PM, Ishara Cooray < >>>>>>>>>>>>>> isha...@wso2.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Motivation:* >>>>>>>>>>>>>>> Before c5, API Manager product REST APIs resources have pre >>>>>>>>>>>>>>> defined scopes and they cannot be changed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But what if an admin needs to give access to Create, Update, >>>>>>>>>>>>>>> Delete actions to different users? >>>>>>>>>>>>>>> if he can customize the scopes associated with each >>>>>>>>>>>>>>> resource, then he will be able to fine grain the access to each >>>>>>>>>>>>>>> resource. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Design:*With C5, we thought of allowing admin users to >>>>>>>>>>>>>>> add/change scopes in product REST APIs to meet their fine >>>>>>>>>>>>>>> grained >>>>>>>>>>>>>>> requirements. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the moment we can think of two ways to do this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>1. *Allow to edit the scopes defined per resource * >>>>>>>>>>>>>>>In this case we can copy the swagger file into conf >>>>>>>>>>>>>>>directory at build time, so that it can be maintained as a >>>>>>>>>>>>>>> usual >>>>>>>>>>>>>>>configuration file. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When server startup we can copy these swagger files to conf >>>>>>>>>>>>>> directory and refer it from there. Maintain separate file for >>>>>>>>>>>>>> mapping make >>>>>>>>>>>>>> things more complex IMO. >>>>>>>>>>>>>> Lets follow this for all swagger based APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> sanjeewa. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>1. >>>>>>>>>>>>>>> 2. *Introduce a new config file to track resource to scope >>>>>>>>>>>>>>>mapping.* >>>>>>>>>>>>>>>In this case the issue is resource to scope mapping will >>>>>>>>>>>>>>>be duplicated. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Appreciate your insight on this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>> Ishara Cooray >>>>>>>>>>>>>>> Senior Software Engineer >>>>>>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>>>>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>>>> >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>> >>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>> email : nuw...@wso2.com >>>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>>> WSO2 Inc. >>>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>>> >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Nuwan Dias >>>>>>>>>>> >>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>> email : nuw...@wso2.com >>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>> WSO2 Inc. >>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>> >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Nuwan Dias >>>>>>>>> >>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>> email : nuw...@wso2.com >>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Sanjeewa Malalgoda* >>>>>>>> WSO2 Inc. >>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>> >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>> email : nuw...@wso2.com >>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 <071%20306%208779> >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 <077%20777%205729> >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : nuw...@wso2.com >> Phone : +94 777 775 729 <+94%2077%20777%205729> >> > > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 <+94%2077%20777%205729> > > ___ > 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
Re: [Architecture] Access token for API testing in Publisher and Store
Hi Jo, On 21 April 2017 at 06:23, Joseph Fonseka <jos...@wso2.com> wrote: > Hi Lakmali > > On Thu, Apr 20, 2017 at 11:51 PM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> On 20 April 2017 at 19:19, Joseph Fonseka <jos...@wso2.com> wrote: >> >>> >>> @Jo >> Even though the API is designed to work with client credential, it >> doesn't mean only the subscribed users can invoke it, right? Any user that >> access the subscribed app will be able to invoke that API. My argument is, >> the pattern used in test app is possible in any other normal apps as well. >> I understand that this can be confusing and might be not easy to convince >> for some users. >> > > Your argument assumes that an app is shared/available to all the users. It > can be true for some scenarios like mobile apps but if you look at > instances like B2B ( system to system ) API invocations app will not be > available for all the users or for any user to start with. > yeah.. By default exposing an app with all API subscriptions can be a problem then. Thanks, Lakmali > > Regards > Jo > > > >> >> However, when proceeding with the implementation we found further >> problems which we couldn't find clean enough solutions. >> >>- Getting the admin apps credentials to the front end for swagger can >>be vulnerable. Even if we go for implicit grant type, we have to figure >> out >>how to compose the callback URLs. >>- We can do per user app creation with automatic on demand >>subscriptions (may be with an explicit button as Jo mentioned). If so, >> only >>thing we achieve here compared to C4 is doing an automatic >>subscription/token generation for a default app. >> >> So for now, we'll be integrating API Console only for editor and Store. >> Since API doesn't have security applied in Editor mode, we don't have to >> worry about token generation. For Store, we will keep the same behavior as >> in C4 for now. >> >> Thanks, >> Lakmali >> >> >>> Regards >>> Jo >>> >>> >>>> >>>> Thanks, >>>> Lakmali >>>> >>>> I guess to prevent that you have to use a per user or per API test app. >>>>> >>>>> Regards >>>>> Jo >>>>> >>>>> On Thu, Apr 20, 2017 at 10:10 AM, Lakmali Baminiwatta < >>>>> lakm...@wso2.com> wrote: >>>>> >>>>>> Hi Jo, >>>>>> >>>>>> On 20 April 2017 at 09:01, Joseph Fonseka <jos...@wso2.com> wrote: >>>>>> >>>>>>> Hi Lakmali >>>>>>> >>>>>>> Small thing, will the portal app subscription be automatic in the >>>>>>> store ? if so can we make it explicit with a button on top of the >>>>>>> swagger >>>>>>> console with the title "Try API with swagger console" and bellow that >>>>>>> we >>>>>>> can explain what actually happens. >>>>>>> >>>>>> >>>>>> We are creating an app for the admin user here and therefore the >>>>>> subscription happens for the admin user. Therefore IMO, that information >>>>>> is >>>>>> not required for the store user. >>>>>> >>>>>>> >>>>>>> Also how will the test app affects stats ? If we are not planing to >>>>>>> hide it better to document that behavior. >>>>>>> >>>>>> >>>>>> The admin user will have this test app. I believe its okay for admin >>>>>> to have this test app shown may be with a special flag. >>>>>> >>>>>> In overall, we can explain the underlying process here when we >>>>>> document the options users will have around this. >>>>>> >>>>>> Thanks, >>>>>> Lakmali >>>>>> >>>>>> >>>>>>> Thanks >>>>>>> Jo >>>>>>> >>>>>>> On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta < >>>>>>> lakm...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> We had a discussion regarding this yesterday and please find the >>>>>>>> s
Re: [Architecture] Access token for API testing in Publisher and Store
On 20 April 2017 at 19:19, Joseph Fonseka <jos...@wso2.com> wrote: > > > On Thu, Apr 20, 2017 at 5:17 PM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: >> >> >> So here also, the store users are end users of the test application where >> they can invoke any subscribed APIs with a valid token. Given that we will >> set proper throttling limits as well, I think its not a security >> vulnerability. >> > > Hmm I think still there is an issue, If you consider an API which is > designed to work with client credentials grant the authorization to access > the API will be granted when you subscribe to the API. In the above case > you will get access to the API without subscribing to it ( which I think is > a fundamental issue ). > @Jo Even though the API is designed to work with client credential, it doesn't mean only the subscribed users can invoke it, right? Any user that access the subscribed app will be able to invoke that API. My argument is, the pattern used in test app is possible in any other normal apps as well. I understand that this can be confusing and might be not easy to convince for some users. However, when proceeding with the implementation we found further problems which we couldn't find clean enough solutions. - Getting the admin apps credentials to the front end for swagger can be vulnerable. Even if we go for implicit grant type, we have to figure out how to compose the callback URLs. - We can do per user app creation with automatic on demand subscriptions (may be with an explicit button as Jo mentioned). If so, only thing we achieve here compared to C4 is doing an automatic subscription/token generation for a default app. So for now, we'll be integrating API Console only for editor and Store. Since API doesn't have security applied in Editor mode, we don't have to worry about token generation. For Store, we will keep the same behavior as in C4 for now. Thanks, Lakmali > Regards > Jo > > >> >> Thanks, >> Lakmali >> >> I guess to prevent that you have to use a per user or per API test app. >>> >>> Regards >>> Jo >>> >>> On Thu, Apr 20, 2017 at 10:10 AM, Lakmali Baminiwatta <lakm...@wso2.com> >>> wrote: >>> >>>> Hi Jo, >>>> >>>> On 20 April 2017 at 09:01, Joseph Fonseka <jos...@wso2.com> wrote: >>>> >>>>> Hi Lakmali >>>>> >>>>> Small thing, will the portal app subscription be automatic in the >>>>> store ? if so can we make it explicit with a button on top of the swagger >>>>> console with the title "Try API with swagger console" and bellow that we >>>>> can explain what actually happens. >>>>> >>>> >>>> We are creating an app for the admin user here and therefore the >>>> subscription happens for the admin user. Therefore IMO, that information is >>>> not required for the store user. >>>> >>>>> >>>>> Also how will the test app affects stats ? If we are not planing to >>>>> hide it better to document that behavior. >>>>> >>>> >>>> The admin user will have this test app. I believe its okay for admin to >>>> have this test app shown may be with a special flag. >>>> >>>> In overall, we can explain the underlying process here when we document >>>> the options users will have around this. >>>> >>>> Thanks, >>>> Lakmali >>>> >>>> >>>>> Thanks >>>>> Jo >>>>> >>>>> On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta <lakm...@wso2.com >>>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> We had a discussion regarding this yesterday and please find the >>>>>> summarized points. >>>>>> >>>>>> >>>>>>- "Testing APIs" is a required feature for Store and Editor >>>>>>portals. Since we are not restricting API designing only to the >>>>>> editor, but >>>>>>allowed in publisher too, it is good to have "Testing APIs" feature in >>>>>>Publisher for a complete story. >>>>>>- For editor, since the API is published to a local GW, it will >>>>>>not have any security and therefore testing API will not require any >>>>>>tokens/subscriptions etc. >>>>>>- When the API i
Re: [Architecture] Access token for API testing in Publisher and Store
Hi Jo, On 20 April 2017 at 09:01, Joseph Fonseka <jos...@wso2.com> wrote: > Hi Lakmali > > Small thing, will the portal app subscription be automatic in the store ? > if so can we make it explicit with a button on top of the swagger console > with the title "Try API with swagger console" and bellow that we can > explain what actually happens. > We are creating an app for the admin user here and therefore the subscription happens for the admin user. Therefore IMO, that information is not required for the store user. > > Also how will the test app affects stats ? If we are not planing to hide > it better to document that behavior. > The admin user will have this test app. I believe its okay for admin to have this test app shown may be with a special flag. In overall, we can explain the underlying process here when we document the options users will have around this. Thanks, Lakmali > Thanks > Jo > > On Thu, Apr 20, 2017 at 8:17 AM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> Hi all, >> >> We had a discussion regarding this yesterday and please find the >> summarized points. >> >> >>- "Testing APIs" is a required feature for Store and Editor portals. >>Since we are not restricting API designing only to the editor, but allowed >>in publisher too, it is good to have "Testing APIs" feature in Publisher >>for a complete story. >>- For editor, since the API is published to a local GW, it will not >>have any security and therefore testing API will not require any >>tokens/subscriptions etc. >>- When the API is published from Publisher portal to the GW in >>CREATED state for testing, we have to apply standard security/throttling >> to >>avoid security risks. >>- As discussed in this thread as well, we will be using the OAuth app >>created for the portals as the test app. However, for supporting prod and >>sandbox tokens, we have to register 2 apps. >>- We can create the test apps when doing the DCR call. >>- When retrieving the swagger definition of the API, we can check the >>availability of subscriptions against the test apps and add if not >>available. >>- Since swagger itself support OAuth, we can rely on it to obtain a >>token. For that, we need to inject the test app's credentials to swagger >> UI >>and KM details needs to be injected to swagger definition. >>- We can have a special throttling tier for API testing purpose. >>- As the first step, we can implement this for Store and then decide >>on adding it to Publisher. >> >> >> Thanks, >> Lakmali >> >> On 24 March 2017 at 19:08, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> Hi Jo, >>> >>> The publisher and store are anyway OAuth apps registered in the IDP. >>> There are registered under the system/admin user. That is done irrespective >>> of the testing usecase so that those apps can use the OAuth protected Rest >>> APIs. >>> >>> Regarding stats, the stats against the API will show that there are >>> requests being being from the publisher/store webapps. Which is what >>> happens in reality. The stats against the application will only be visible >>> to the system/admin user since the publisher/store webapps belong to him. >>> So it doesn't confuse the end user (actual App Developer on the Store) like >>> it does today. >>> >>> My thinking is that this testing of the API is mainly for the API >>> Developers (not publishers) to test the API Implementation code (ballerina >>> code) they write. Testing OAuth and throttling are just by-products of the >>> main usecase. >>> >>> Thanks, >>> NuwanD. >>> >>> On Fri, Mar 24, 2017 at 4:40 PM, Joseph Fonseka <jos...@wso2.com> wrote: >>> >>>> >>>> On Fri, Mar 24, 2017 at 10:20 AM, Nuwan Dias <nuw...@wso2.com> wrote: >>>> >>>> @Jo, what's the downside of using the Publisher/Store webapp that >>>>> you're trying to get rid of by explicitly creating a test app? What's the >>>>> difference basically? >>>>> >>>> >>>> The main issue I see is that automatic subscription of store and >>>> publisher app. Once subscribed it will come up in IdP , Stats ( If we >>>> capture ) which will confuse the end user. The second issue is that >>>> majority of APIs will be just proxy-ed though GW and you wont be testing >>>> th
Re: [Architecture] Access token for API testing in Publisher and Store
On 24 March 2017 at 16:40, Joseph Fonseka <jos...@wso2.com> wrote: > > On Fri, Mar 24, 2017 at 10:20 AM, Nuwan Dias <nuw...@wso2.com> wrote: > > @Jo, what's the downside of using the Publisher/Store webapp that you're >> trying to get rid of by explicitly creating a test app? What's the >> difference basically? >> > > The main issue I see is that automatic subscription of store and publisher > app. Once subscribed it will come up in IdP , Stats ( If we capture ) which > will confuse the end user. > Here we will be creating an application for the admin user and the API developer will be just an end user of that app. > The second issue is that majority of APIs will be just proxy-ed though GW > and you wont be testing the BE functionality at this stage so what you > would do is more of an integration test with OAuth and throttling hence the > user should be able to utilize all grant types and scopes. > I would say we are targeting the API developers who want to test their API code. API scopes can be verified here since the access token retrieved will be taken by providing the API's scopes. I think testing the grant types is needed for App developers. Thanks, Lakmali > > Regards > Jo > > >> I see a few negatives in allowing to create test apps from the Publisher. >> >> 1. The UX is definitely not as good since the user now has to go through >> additional steps just to test his API. >> 2. There will be lots of test apps created in the system as opposed to >> the two webapps. >> 3. If by any chance the same user visits the Store, we have to find >> mechanisms to differentiate his test Apps from the Standard Apps so that >> the test Apps don't appear in Store. >> 4. If we open up an App creation functionality on the Publisher, chances >> are that users will misuse this for other purposes. >> >> >> On Fri, Mar 24, 2017 at 10:06 AM, Lakmali Baminiwatta <lakm...@wso2.com> >> wrote: >> >>> The objective of providing this feature is making the API >>> developers/publisher to test and verify before make it available for the >>> consumers. So how about we provide the ability to deploy it to the gateway >>> without security so that it can be invoked without a token? >>> Once the test is completed, they can set the security and publish that >>> to the store/gateway. >>> >>> Thanks, >>> Lakmali >>> >>> >>> On 24 March 2017 at 09:34, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> >>>> >>>> On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda <sanje...@wso2.com >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda < >>>>>> sanje...@wso2.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias <nuw...@wso2.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka <jos...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I guess there is a possibility of that API developer not being >>>>>>>>> the one who publish / create the API ? >>>>>>>>> >>>>>>>> >>>>>>>> Yes, the API Developer may not be the same one who's publishing the >>>>>>>> it. But what's wrong with him testing the API under development using a >>>>>>>> valid token? >>>>>>>> >>>>>>> If this is valid argument then person who create APIs can consume >>>>>>> it. If we consider scenario where we develop API and later it published >>>>>>> and >>>>>>> appear in gateways, just because I'm developer will i get chance to use >>>>>>> this API? I don't think we should allow it. Even if we say we are >>>>>>> testing >>>>>>> what actually happen is someone invoke API and get results. >>>>>>> >>>>>> >>>>>> In API Manager 3.0.0, the API deployment to the Gateway happens >>>>>> before the Pu
Re: [Architecture] Access token for API testing in Publisher and Store
The objective of providing this feature is making the API developers/publisher to test and verify before make it available for the consumers. So how about we provide the ability to deploy it to the gateway without security so that it can be invoked without a token? Once the test is completed, they can set the security and publish that to the store/gateway. Thanks, Lakmali On 24 March 2017 at 09:34, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda <sanje...@wso2.com> > wrote: > >> >> >> On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> >>> >>> On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >>> wrote: >>> >>>> >>>> >>>> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka <jos...@wso2.com> >>>>> wrote: >>>>> >>>>>> I guess there is a possibility of that API developer not being the >>>>>> one who publish / create the API ? >>>>>> >>>>> >>>>> Yes, the API Developer may not be the same one who's publishing the >>>>> it. But what's wrong with him testing the API under development using a >>>>> valid token? >>>>> >>>> If this is valid argument then person who create APIs can consume it. >>>> If we consider scenario where we develop API and later it published and >>>> appear in gateways, just because I'm developer will i get chance to use >>>> this API? I don't think we should allow it. Even if we say we are testing >>>> what actually happen is someone invoke API and get results. >>>> >>> >>> In API Manager 3.0.0, the API deployment to the Gateway happens before >>> the Publishing phase actually. It gets deployed on the Gateway as soon as >>> its created. >>> >> Why do we deploy API to gateway by the time we created it? Ideally it >> should go to topic and notified only after publishing it. I haven't noticed >> it any of our previous discussions. >> Did i missed something here? >> > > The cause is the same as before. We want to enable API testing on the > publisher itself so that API developers can test their API before > publishing it to the Store. In order to test an API, it should be deployed > on the Gateway. > >> >> Thanks, >> sanjeewa. >> >>> >>> If the API developer accessing a published API with a valid token is a >>> concern, we can automatically remove the publisher webapp's subscription to >>> the API once the API gets published. This will prevent the API developers >>> and publishers from accessing a published API since they no longer have a >>> valid subscription. >>> >>>> >>>> >>>> Thanks, >>>> sanjeewa. >>>> This can be an edge case, but if you consider an API designed to work >>>> with client credentials ie. B2B API, subscription is the authorization >>>> point for that API if so you don't want the creator or publisher on >>>> accessing it ? >>>> >>>> I guess it is fare to ask a user to go though subscription process to >>>> test the published API without magic. WDYT ? >>>> >>>>> >>>>> Well, the point here is that we're trying to provide the facility for >>>>> the Developer to test the API he's developing before publishing it. >>>>> Because >>>>> that's a very valid use case. Asking the developer to publish the API and >>>>> subscribe to it in order to be able to safely test it is not right IMO. >>>>> The >>>>> sole reason he wants to test the API first is because he's not ready to >>>>> publish it yet. >>>>> >>>>>> >>>>>> Thanks & Regards >>>>>> Jo >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 23, 2017 at 2:32 PM, Nuwan Dias <nuw...@wso2.com> wrote: >>>>>> >>>>>>> Why is it a concern? Its only the App developers who have the >>>>>>> subscriber role. Almost all consumers of the API are general users and >>>>>>> hence do not have the subscriber role. So why is it a concern to allow >>>>&g
Re: [Architecture] Access token for API testing in Publisher and Store
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
Re: [Architecture] Access token for API testing in Publisher and Store
Hi Prasanna, On 23 March 2017 at 08:53, Prasanna Dangalla <prasa...@wso2.com> wrote: > > On Thu, Mar 23, 2017 at 8:28 AM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> Hi all, >> >> Prior to C5, we were generating an access token per app created in the >> store using the client_credentials grant type and it was displayed to be >> used as the test tokens. The same was used in the API Console as well. Due >> to below reasons we are going to generate a token against the OAuth app >> registered for the UUF app and make it available as the test token. >> >>- 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. >>- Make it possible to do a test API call without subscribing. >>- Provide Swagger API Console in Publisher as well. >> >> 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? >> > > Hi Lakmali, > > In this approach how are we going to restrict the users using this testing > access token in API console and in real use cases. Let say a user is logged > in and using this access token. At that time, would they be able to use it > from API console? > Actually we don't have any explicit restriction. Only thing is this token will have a limited quota. Thanks, Lakmali > > >> Thanks, >> Lakmali >> >> >> -- >> Lakmali Baminiwatta >> Associate Technical Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> mobile: +94 71 2335936 >> blog : lakmali.com >> >> > -- 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
[Architecture] Access token for API testing in Publisher and Store
Hi all, Prior to C5, we were generating an access token per app created in the store using the client_credentials grant type and it was displayed to be used as the test tokens. The same was used in the API Console as well. Due to below reasons we are going to generate a token against the OAuth app registered for the UUF app and make it available as the test token. - 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. - Make it possible to do a test API call without subscribing. - Provide Swagger API Console in Publisher as well. 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
Re: [Architecture] [VOTE] Release WSO2 API Manager 2.1.0 RC4
Tested below scenarios for ST and tenants. 1. JWT token 2. Authorization code grant type 3. Implicit grant type 4. Password grant type 5. Scopes 6. SaaS Apps 7. API Walkthrough [+] Stable - Go ahead and release On 1 February 2017 at 07:07, Isuru Haththotuwa <isu...@wso2.com> wrote: > Tested the following: > > 1. Basic API creation, updating, subscription and invocation flows > 2. Workflows for application creation and API subscription > > [+] Stable - go ahead and release > > On Mon, Jan 30, 2017 at 10:28 PM, Malintha Amarasinghe <malint...@wso2.com > > wrote: > >> Hi All, >> >> This is the 4th Release Candidate of WSO2 API Manager 2.1.0 >> >> Please download, test the product and vote. The vote will be open for 72 >> hours or as needed. >> >> Source and distribution >> >> Run-time : https://github.com/wso2/product-apim/releases/download/v2. >> 1.0-rc4/wso2am-2.1.0-RC4.zip >> Analytics : https://github.com/wso2/anal >> ytics-apim/releases/download/v2.1.0-rc3/wso2am-analytics-2.1.0-RC3.zip >> Tooling : https://github.com/wso2/devstudio-tooling-apim/releases/ta >> g/v2.1.0-rc2 >> >> >> This release fixes the following issues: >> Runtime : https://wso2.org/jira/issues/?filter=13623 >> Analytics : https://wso2.org/jira/issues/?filter=13624 >> Tooling : https://wso2.org/jira/browse/DEVTOOLAPI-1 >> >> >> Please vote as follows. >> [+] Stable - go ahead and release >> [-] Broken - do not release (explain why) >> >> Thanks, >> - WSO2 API Manager Team - >> >> -- >> Malintha Amarasinghe >> Software Engineer >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 <+94%2071%20238%203306> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>* > > > > ___ > 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
Re: [Architecture] Increasing size of VALUE column of AM_BLOCK_CONDITIONS table
For now there are no constraints for that table. Anyway 512 should be
sufficient.
On 2 December 2016 at 09:22, Sanjeewa Malalgoda <sanje...@wso2.com> wrote:
> Yes if we have constraints it may effect. But i also feel 512 is enough.
>
> Thanks,
> sanjeewa.
>
> On Thu, Dec 1, 2016 at 5:11 PM, Lakmali Baminiwatta <lakm...@wso2.com>
> wrote:
>
>> yeah, practically 512 should be sufficient.
>>
>> On 1 December 2016 at 16:59, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Ok, how about 512 :) ? I'm ok to increase length but as needed only. The
>>> reason being that the column length becomes a problem on certain database
>>> types if/when we use that column in certain constraints (ex: unique
>>> constraint).
>>>
>>> On Thu, Dec 1, 2016 at 4:50 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>>> wrote:
>>>
>>>> Blocking condition values will include the tenant domain for API
>>>> context blocking(/t/${tenantDomain}/${context}) and tenant qualified
>>>> username for Application blocking (${userName}:${applicationName}).
>>>> Especially if email username based tenant users are there, value can grow
>>>> more.
>>>> Hence suggesting a higher value.
>>>>
>>>> On 1 December 2016 at 16:43, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> Isn't 256 enough? Since the application or api name length is 200?
>>>>>
>>>>> On Thu, Dec 1, 2016 at 3:45 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Shall we do the $subject?
>>>>>>
>>>>>> Currently the 'value' column size is varchar(45), which is not
>>>>>> sufficient for most possible combinations, given that we allow API name
>>>>>> and
>>>>>> Application name themselves 200/100 chars.
>>>>>>
>>>>>> So I think we can increase 'value' cloumn size to 1024.
>>>>>> We can include an alter query for 2.1.0 default script for migration.
>>>>>>
>>>>>>
>>>>>> Any concerns?
>>>>>>
>>>>>> Thanks,
>>>>>> Lakmali
>>>>>> --
>>>>>> Lakmali Baminiwatta
>>>>>> Associate Technical Lead
>>>>>> WSO2, Inc.: http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>> mobile: +94 71 2335936
>>>>>> blog : lakmali.com
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Software Architect - WSO2, Inc. http://wso2.com
>>>>> email : nuw...@wso2.com
>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Lakmali Baminiwatta
>>>> Associate Technical Lead
>>>> WSO2, Inc.: http://wso2.com
>>>> lean.enterprise.middleware
>>>> mobile: +94 71 2335936
>>>> blog : lakmali.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>>
>> --
>> Lakmali Baminiwatta
>> Associate Technical Lead
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile: +94 71 2335936
>> blog : lakmali.com
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.
> blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
>
>
>
--
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
Re: [Architecture] Increasing size of VALUE column of AM_BLOCK_CONDITIONS table
yeah, practically 512 should be sufficient.
On 1 December 2016 at 16:59, Nuwan Dias <nuw...@wso2.com> wrote:
> Ok, how about 512 :) ? I'm ok to increase length but as needed only. The
> reason being that the column length becomes a problem on certain database
> types if/when we use that column in certain constraints (ex: unique
> constraint).
>
> On Thu, Dec 1, 2016 at 4:50 PM, Lakmali Baminiwatta <lakm...@wso2.com>
> wrote:
>
>> Blocking condition values will include the tenant domain for API context
>> blocking(/t/${tenantDomain}/${context}) and tenant qualified username
>> for Application blocking (${userName}:${applicationName}). Especially if
>> email username based tenant users are there, value can grow more.
>> Hence suggesting a higher value.
>>
>> On 1 December 2016 at 16:43, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>> Isn't 256 enough? Since the application or api name length is 200?
>>>
>>> On Thu, Dec 1, 2016 at 3:45 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>>> wrote:
>>>
>>>> Shall we do the $subject?
>>>>
>>>> Currently the 'value' column size is varchar(45), which is not
>>>> sufficient for most possible combinations, given that we allow API name and
>>>> Application name themselves 200/100 chars.
>>>>
>>>> So I think we can increase 'value' cloumn size to 1024.
>>>> We can include an alter query for 2.1.0 default script for migration.
>>>>
>>>> Any concerns?
>>>>
>>>> Thanks,
>>>> Lakmali
>>>> --
>>>> Lakmali Baminiwatta
>>>> Associate Technical Lead
>>>> WSO2, Inc.: http://wso2.com
>>>> lean.enterprise.middleware
>>>> mobile: +94 71 2335936
>>>> blog : lakmali.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Software Architect - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729 <+94%2077%20777%205729>
>>>
>>
>>
>>
>> --
>> Lakmali Baminiwatta
>> Associate Technical Lead
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile: +94 71 2335936
>> blog : lakmali.com
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
--
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
Re: [Architecture] Increasing size of VALUE column of AM_BLOCK_CONDITIONS table
Blocking condition values will include the tenant domain for API context
blocking(/t/${tenantDomain}/${context}) and tenant qualified username for
Application blocking (${userName}:${applicationName}). Especially if email
username based tenant users are there, value can grow more.
Hence suggesting a higher value.
On 1 December 2016 at 16:43, Nuwan Dias <nuw...@wso2.com> wrote:
> Isn't 256 enough? Since the application or api name length is 200?
>
> On Thu, Dec 1, 2016 at 3:45 PM, Lakmali Baminiwatta <lakm...@wso2.com>
> wrote:
>
>> Shall we do the $subject?
>>
>> Currently the 'value' column size is varchar(45), which is not sufficient
>> for most possible combinations, given that we allow API name and
>> Application name themselves 200/100 chars.
>>
>> So I think we can increase 'value' cloumn size to 1024.
>> We can include an alter query for 2.1.0 default script for migration.
>>
>> Any concerns?
>>
>> Thanks,
>> Lakmali
>> --
>> Lakmali Baminiwatta
>> Associate Technical Lead
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile: +94 71 2335936
>> blog : lakmali.com
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
--
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
[Architecture] Increasing size of VALUE column of AM_BLOCK_CONDITIONS table
Shall we do the $subject? Currently the 'value' column size is varchar(45), which is not sufficient for most possible combinations, given that we allow API name and Application name themselves 200/100 chars. So I think we can increase 'value' cloumn size to 1024. We can include an alter query for 2.1.0 default script for migration. Any concerns? 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
Re: [Architecture] APIM C5 - Schema for handling resources stored as blobs
I think for storing DOCUMENT_INLINE content also, we will have to use BLOB since it could be some rich HTML content. Thanks, Lakmali On 3 November 2016 at 16:40, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > Adding more information, > > The reason for the DATA_TYPE column is, > > 1. As mentioned earlier, if the DATA_TYPE is TEXT the resource value is > stored in the VARCHAR column else it will be stored in the BLOB column > 2. In the case of images we need to know the specific MIME type in order > to render in the UI so we need to store those specifically > > On 3 November 2016 at 16:01, Uvindra Dias Jayasinha <uvin...@wso2.com> > wrote: > >> Hi All, >> >> Currently APIs have a few resources such as Swagger File, Optional WSDL >> file, Related Documents file and an Optional Thumbnail image that needs to >> be stored as blobs in the DB. >> >> Initially we thought of having separate tables to store these resources, >> but what if we have a single generic resource table to store all these? >> >> We could have schema such as below for the generic resource table >> >> >> Since we previously stored our resources in the registry, a similar >> generic schema was used to store all such resources by the registry itself. >> So anything that is not a text data type can be considered as a BLOB. >> >> The advantages of doing this are, >> >> 1. Can manage all API related resources from a central table without >> having to define custom tables for each resource. >> >> 2. When an API is deleted its very easy to locate and remove all the >> resources related with it >> >> 3. When a new version of an API is created its very easy to copy over the >> resources associated with the previous version to the new one. >> >> WDYT? >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 33962 >> > > > > -- > Regards, > Uvindra > > Mobile: 33962 > -- 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
Re: [Architecture] Storing configs in database for C5
On 12 October 2016 at 14:31, Nuwan Dias <nuw...@wso2.com> wrote: > There are challenges when moving configs to the DB. We experienced it once > when we moved the analytics configs to the registry. And then we moved it > back again to the FS because it was too painful to maintain. > > 1. The nodes have to keep polling the DB in a fast enough interval. This > is a unnecessary performance overhead. Because in practise, someone will > only change these configs once. But to support that use case, we have to > keep polling the DB for life. > > 2. Gateways don't have access to the DB. So say you're enabling analytics > (data publishing). You have to propagate that change to the Gateway nodes > using some mechanism. And with no clustering on C5, this is a challenge. > > If the objective of this is to make the Cloud (tenant) experience better, > I think we should just restart the tenant's containers with the relevant > configs in place. > Still we have a problem with regard to how we are going to allow the tenants to do the configuration changes. Currently we do it through the registry which will not work for C5. Thanks, Lakmali > > Thanks, > NuwanD. > > On Wed, Oct 12, 2016 at 2:12 PM, Lakmali Baminiwatta <lakm...@wso2.com> > wrote: > >> >> >> On 12 October 2016 at 13:47, Uvindra Dias Jayasinha <uvin...@wso2.com> >> wrote: >> >>> Hi Sajith, >>> >>> Yes even though the boot up time is not an issue in C5 the other >>> advantages I have outlined are still there to be gained. There is a huge >>> effort we have to do on dev ops side to maintain those images you are >>> talking about because of having everything at file level. >>> >>> Some examples from API Manager I can think of are turning notifications >>> on/off, enable monetization, enable/disable stats, configure work flows, >>> Enable/Disable JWT token header. >>> >> >> +1 to move feature related configurations to the database and make them >> configurable through the UI. >> >> Thanks, >> Lakmali >> >>> >>> >>> >>> On 12 October 2016 at 12:58, Sajith Kariyawasam <saj...@wso2.com> wrote: >>> >>>> Hi Uvindra, >>>> >>>> With cloud deployment in mind, the idea is to boot up the nodes in >>>> quick time, therefore the docker images are pre-configured with all the >>>> configuration values, which will speed up the node start up. A change of >>>> configuration means a new docker image will be created with the new >>>> configs, and re-spawn the cluster. >>>> >>>> Therefore, IMO a node restart for a config change is not relevant, also >>>> no need of a periodic config checks. >>>> >>>> Btw, can you give me some example configuration you were thinking of? >>>> >>>> Thanks, >>>> Sajith >>>> >>>> On Wed, Oct 12, 2016 at 11:53 AM, Uvindra Dias Jayasinha < >>>> uvin...@wso2.com> wrote: >>>> >>>>> Was wondering about $subject >>>>> >>>>> Traditionally we have stored our product configs, be it carbon.xml, >>>>> api-manager.xml, identity.xml, etc. at file level. Some configs, such as >>>>> "port offset" are inherently bound to the server startup so it makes sense >>>>> for them to be at file level, since they come into affect during the >>>>> startup. But certain runtime configs actually get engaged only when a >>>>> given >>>>> feature is used. But having those configs at file level require a restart >>>>> for the changes to take affect. In C4 API Manager avoided doing restarts >>>>> for certain config changes, like adding mediation extensions, by storing >>>>> them in the registry. >>>>> >>>>> For C5 a reusable implementation can exist at each node which >>>>> periodically reads the table(say once a minute) and updates the config >>>>> values in memory. Products communicate with this config library to get the >>>>> values of a given config. So eventually they will read the updated value >>>>> in >>>>> a short time. If we were to store at least certain configs at DB level >>>>> there are several advantages. >>>>> >>>>> 1. Eliminate need for a restart for changes to take affect. I realize >>>>> in C5 a restart is relatively cheap so this might not be a big deal, but >>>>> yo
Re: [Architecture] Storing configs in database for C5
On 12 October 2016 at 13:47, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > Hi Sajith, > > Yes even though the boot up time is not an issue in C5 the other > advantages I have outlined are still there to be gained. There is a huge > effort we have to do on dev ops side to maintain those images you are > talking about because of having everything at file level. > > Some examples from API Manager I can think of are turning notifications > on/off, enable monetization, enable/disable stats, configure work flows, > Enable/Disable JWT token header. > +1 to move feature related configurations to the database and make them configurable through the UI. Thanks, Lakmali > > > > On 12 October 2016 at 12:58, Sajith Kariyawasam <saj...@wso2.com> wrote: > >> Hi Uvindra, >> >> With cloud deployment in mind, the idea is to boot up the nodes in quick >> time, therefore the docker images are pre-configured with all the >> configuration values, which will speed up the node start up. A change of >> configuration means a new docker image will be created with the new >> configs, and re-spawn the cluster. >> >> Therefore, IMO a node restart for a config change is not relevant, also >> no need of a periodic config checks. >> >> Btw, can you give me some example configuration you were thinking of? >> >> Thanks, >> Sajith >> >> On Wed, Oct 12, 2016 at 11:53 AM, Uvindra Dias Jayasinha < >> uvin...@wso2.com> wrote: >> >>> Was wondering about $subject >>> >>> Traditionally we have stored our product configs, be it carbon.xml, >>> api-manager.xml, identity.xml, etc. at file level. Some configs, such as >>> "port offset" are inherently bound to the server startup so it makes sense >>> for them to be at file level, since they come into affect during the >>> startup. But certain runtime configs actually get engaged only when a given >>> feature is used. But having those configs at file level require a restart >>> for the changes to take affect. In C4 API Manager avoided doing restarts >>> for certain config changes, like adding mediation extensions, by storing >>> them in the registry. >>> >>> For C5 a reusable implementation can exist at each node which >>> periodically reads the table(say once a minute) and updates the config >>> values in memory. Products communicate with this config library to get the >>> values of a given config. So eventually they will read the updated value in >>> a short time. If we were to store at least certain configs at DB level >>> there are several advantages. >>> >>> 1. Eliminate need for a restart for changes to take affect. I realize in >>> C5 a restart is relatively cheap so this might not be a big deal, but you >>> still need someone to initiate the restart after the config change. >>> >>> 2. Since the config DB table has a known structure a UI can be easily >>> developed to do CRUD operations for config changes and used by all >>> products. This is a lot more user friendly than asking users to change >>> files. >>> >>> 3. We can provide a REST API to allow config changes to be done on the >>> DB table alternatively. >>> >>> 4. Simplify dev ops by eliminating complicated puppet config templates >>> that need to constantly maintained with new releases. >>> >>> 5. Since configs are in a central DB its easy to manage them since all >>> nodes will read from the same table. >>> >>> 6. Configs can be backed up by simply backing up the table >>> >>> >>> Doing this makes sense for certain use cases of API Manger, I'm sure >>> there maybe similar benefits for other products as well. It may not make >>> sense for all configs but at least for some that govern feature >>> functionality its great to have. WDYT? >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 33962 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sajith Kariyawasam >> *Associate Tech Lead* >> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >> *Committer and PMC member, Apache Stratos * >> *AMIE (SL)* >> *Mobile: 0772269575* >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > 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
Re: [Architecture] Review DB table audit fields for API Manager C5
On 11 October 2016 at 14:40, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote: > Thanks for the feedback, some interesting points were brought up > > @Abimaran, the problem with maintaining a rigid structure like old/new > column is that if a user changes the value of 5 columns at a given time > that would mean 5 different inserts to the table, when in actual fact it > was a single transaction that took place when the user did the change and > saved. So its better to use a implementation like > google-diff-match-patch[1] to record the string diff between the values of > the columns before the change took place and after the update. Though we > dont need to worry about this implementation detail for now. The idea of > using a single table to store the history of all tables that will require > auditing sounds good. > IMO we have to think bit more on whether we really need to store the diff correspond to the changes since it may result in a considerable growth of the storage mainly during the development phase. Also the implementation could be complicated in terms of what columns to be considered since the changes may take place in more than a single table for an artifact update. Thanks, Lakmali > > @Sanjeewa, yes this would improve performance when trying to retreive the > LAST_UPDATED_TIME for a given entity. > > Let me elaborate a bit on Sanjeewa's point. So there can be only one > CREATED_BY and CREATED_TIME for a given entity so that can remain as part > of the original entities schema. Having the LAST_UPDATED_TIME as part of > the original entities schema gives a performance advantage on checking if a > given entity has been modified since it was last checked. This is vital for > features such as ETags support for the REST API. So CREATED_BY, > CREATED_TIME, LAST_UPDATED_TIME can remain with the original entities > schema. > > We can still use the master audit table(building on Abimarans idea) to > actually keep track of change history of a given entity, so that table > could look like this, > > ENTRY_ID PK > TABLE_NAME VARCHAR > ENTITY_ID FK > DIFF BLOB > ACTION*VARCHAR* > ACTION_BY *VARCHAR* > ACTION_TIME *TIMESTAMP* > > > > [1] https://code.google.com/p/google-diff-match-patch/ > > On 11 October 2016 at 13:44, Sanjeewa Malalgoda <sanje...@wso2.com> wrote: > >> I think we can manage audit table while still having CREATED_BY, >> CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that >> approach we may never need to do table scan of audit table while fetching >> updates. So each updates will recorded in separate table while original >> table having all relevant information. WDYT? >> >> Thanks, >> sanjeewa. >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 33962 > > ___ > 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
[Architecture] WSO2 API Manager 1.9.0 Alpha Released!
https://wso2.org/jira/browse/APIMANAGER-2787] -
Mis-spellings in the code for 'tenant' as 'tennat'
- [APIMANAGER-3351 https://wso2.org/jira/browse/APIMANAGER-3351] -
Improving Statistics graphs
- [APIMANAGER-3388 https://wso2.org/jira/browse/APIMANAGER-3388] -
Update API Manager to the latest Swagger version (2.0)
- [APIMANAGER-3395 https://wso2.org/jira/browse/APIMANAGER-3395] -
Need to provide proper instructions when adding tags to apis
- [APIMANAGER-3420 https://wso2.org/jira/browse/APIMANAGER-3420] -
Swagger v2.0 support for APIM
- [APIMANAGER-3431 https://wso2.org/jira/browse/APIMANAGER-3431] -
Override IP address with end user IP address for GA
- [APIMANAGER-3465 https://wso2.org/jira/browse/APIMANAGER-3465] -
Allow changing user password in API store.
- [APIMANAGER-3466 https://wso2.org/jira/browse/APIMANAGER-3466] -
Adding loading Indicators to buttons in API Design wizard
- [APIMANAGER-3467 https://wso2.org/jira/browse/APIMANAGER-3467] -
CORS Improvements
Moderation
- [APIMANAGER-3412 https://wso2.org/jira/browse/APIMANAGER-3412] -
Ability to use deferent context path for registry in reverse proxy
environments
New Feature
- [APIMANAGER-3415 https://wso2.org/jira/browse/APIMANAGER-3415] -
Providing a way to add event receiver and analyser configurations through
UI in APIM
Patch
- [APIMANAGER-1970 https://wso2.org/jira/browse/APIMANAGER-1970] -
Identify unsatisfied components in server startup - APIM
Task
- [APIMANAGER-3429 https://wso2.org/jira/browse/APIMANAGER-3429] -
Test case for API SCOPE to test access with different roles
- [APIMANAGER-3445 https://wso2.org/jira/browse/APIMANAGER-3445] -
Rename API Copy button as Create Version
Your feedback are most welcome !!! Please report all the Jiras at [6] and
specify the affected version as 1.9.0 Alpha
https://wso2.org/jira/browse/APIMANAGER/fixforversion/11768.
[1]
https://github.com/wso2/product-apim/releases/download/v1.9.0-Alpha/wso2am-1.9.0-SNAPSHOT.zip
[2] https://docs.wso2.com/display/AM190/WSO2+API+Manager+Documentation
[3] AM Store : https://{host}:{9763}/store
[4] AM Publisher : https://{host}:{9763}/publisher
[5] AM Roadmap :
https://wso2.org/jira/browse/APIMANAGER#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
[6] https://wso2.org/jira/browse/APIMANAGER
Thanks,
API Manager Team.
--
Lakmali Baminiwatta
Senior Software Engineer
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
Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.
Hi, On 14 January 2015 at 00:32, Joseph Fonseka jos...@wso2.com wrote: Hi With related to CORS the headers they should be set in the gateway as well since we are configuring CORS in gateway so the headers should be as the configuration of the gateway not the back-end. +1. OPTIONS verb exposed through API Gateway should return the supported headers of the relevant resource in the API Gateway. If the back-end supports all the HTTP verbs, but mapped API resource only supports GET, then returning allowed methods of the back-end in not correct. Thanks, Lakmali Also we can capture allowed domains per API basis. Allowed methods and headers are already captured in API definition. Regards Jo On Tue, Jan 13, 2015 at 3:37 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka jos...@wso2.com wrote: Hi Currently in API Manager we send the OPTIONS call to the back-end server to respond. But if the API does not expose all the HTTP methods in back-end, OPTIONS call response will be invalid. 1. Should we respond to the OPTIONS call from the gateway with the Allow header including only the HTTP methods exposed by the API. When we consider CORS use cases preflight call happens as OPTIONS call. So shouldn't we pass them to back end without doing something in gateway? IMO this should be configurable via some kind of configuration. And it would be ideal if we can do this per API level without having global parameter to all APIs in system Thanks, sanjeewa. 2. If we are doing above should we give an option to the user to override in case if he want to send it to back-end. 3. Is there a valid requirement to show the OPTIONS method in API Design phase, shouldn't it be enabled by default. Thanks Jo Related https://wso2.org/jira/browse/APIMANAGER-1704 -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * http://lk.linkedin.com/in/rumeshbandara* -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/ http://sanjeewamalalgoda.blogspot.com/ -- -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * http://lk.linkedin.com/in/rumeshbandara* -- Lakmali Baminiwatta Senior Software Engineer 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
[Architecture] Destination based usage tracking in API Manager
Hi all, I am working on implementing $subject. At the moment we are using a synapse handler (APIMgtUsageHandler) to publish usage data. It is getting invoked for every request and response which reaches the gateway. But we don't have a way to collect stats for requests that leaves the gateway based on where it went. This become very useful for cases where the same API can reach different endpoints (ex: Loadbalanced endpoints) As a solution we are hoping to the below. 1. In the start-up, create a bam profile config with a stream definition for publishing required information. This happens only if usage tracking is enabled. 2. Add an option in create API page to enable destination based usage tracking. 3. If above enabled, 3.1 Add new property to endpoint config of API synapse configuration to track where request went. 3.2 Add BAM mediator after the send mediator. 3. Update API manager analytic toolbox with new Hive queries to summarize destination based data. 4. Add new graph to APIM Statistics dashboard showing number of access to destination addresses by each API. Thanks, Lakmali -- Lakmali Baminiwatta Software Engineer 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
Re: [Architecture] API Manager External Stores Configuration Improvements
Hi Jasintha, On 28 February 2014 05:52, Jasintha Dasanayake jasin...@wso2.com wrote: Hi Lakmali Yes, this is a required improvement , there are couple of clients already tried out this feature. AFAIK currently, publisher cannot remove an API once it is published to the external stores. will it be allowed with this improvement ? or have we done that purposely ? It is possible to delete the API once it is published to the external stores. If the original publisher deletes the API, it will get deleted from other stores as well. Thanks, Lakmali Thanks and Regards /Jasintha On Wed, Feb 26, 2014 at 12:36 PM, Lakmali Baminiwatta lakm...@wso2.comwrote: Hi all, In API Manager 1.5.0, we added the support for publishing an API to multiple external API Stores [1]. Currently we need to pre configure the required external stores in the api-manager.xml. Hence we have below limitations. - Can not add external store configurations at runtime. - External store configuration is global and no way to keep per tenant configuration. So we are planning to add this configuration to registry, so that stores can be configured in runtime and also each tenant will have their own confguration. [1]http://docs.wso2.org/display/AM160/Publishing+to+API+Stores Thanks, Lakmali -- Lakmali Baminiwatta Software Engineer 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 -- *Jasintha Dasanayake * *Software EngineerWSO2 Inc. | http://wso2.com http://wso2.com/ lean . enterprise . middleware* *mobile :- 0711368118* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Lakmali Baminiwatta Software Engineer 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
[Architecture] Filtering API subscription tiers based on subscriber roles
Hi all, Currently in APIM, each subscriber can choose any tier when subscribing to an API. There is no way to limit avaiable tiers to a particular user. This feature will allow API publisher to define which tiers are visible for which roles. Changes - to publisher === A new UI is needed to map tiers roles Changes - to store Based on logged in user's roles, the list of tiers being presented @ the point of subscription should be filtered. Implication on existing subscriptions == If the tier has already been used in existing subscription, we should not allow role based restriction to be applied until those subscriptions are removed. Would this be a good strategy? Looking forward for feedback, suggestions . Thanks, Lakmali -- Lakmali Baminiwatta* * Software Engineer 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
Re: [Architecture] APIM Subscription Blocking - allow blocking Production access only
Hi Paul, On 5 July 2013 13:47, Paul Fremantle p...@wso2.com wrote: Agreed. We also need to support having ONLY a sandbox and no production endpoint for beta or early access to new APIs. +1. May be we can add a new API life cycle status, which publishes the API to the store, but allows only SANDBOX access. Will add this to redmine. Thanks, Lakmali Paul On 5 July 2013 08:22, Lakmali Baminiwatta lakm...@wso2.com wrote: Hi all, In API Manager, the API creator can block a particular subscription on an API to disable access to it until s/he decides to unblock it again. With this blocking, both production and sandox invocations with that subscription is blocked. But there can be situations where there is a broken app. Then while fixing it, access to sandbox is needed to test the subscription. Therefore this improvement is suggested to block only the production access. Currently in APIM we keep Subscription Status (SUB_STATUS) for a subscription, which is set as BLOCKED once the subscription is blocked. Then in an API call, while doing the key validation it checks the SUB_STATUS for the subscription related to that key and blocks the call if it was in BLOCKED state. So what we can do here is, do the blocking if the Key Type is Production only. Any concerns, thoughts are welcome. Thanks, Lakmali -- Lakmali Baminiwatta* * Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 blog : lakmali.com * * -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo p...@wso2.com wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. -- Lakmali Baminiwatta* * Software Engineer 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
Re: [Architecture] [Dev] Current Status of The Registry REST API and Issues I face when Integrate with APIM
Hi Ragu,
On 6 June 2013 12:01, Sriragu Arudsothy srir...@wso2.com wrote:
Hai All,
First of all, I will explain the architecture of the REST API
implementation. The Registry REST API has two mode of functionality.
1) Standalone mode -
Straight access to Registry REST API. This has been done and working fine.
In this case Registry provide a way to generate the OAuth Access token for
users to access the resources.
According to the documentation[1], one should be able to generate a token
by clicking 'Get My Access Token' in Configure-Users and Roles. But in the
GREG 4.6.0 pack which you provided, we can't find such an option. Am I
missing something?
[1] http://docs.wso2.org/wiki/display/Governance460/Generate+OAuth+Access+Token
Thanks,
Lakmali
Therefore the REST calls can be made from any REST client with an access
token to access the resources.
2) With API Manager Mode -
This means the access to Registry REST API with the Externally running API
manager instance. In here, the admin or any responsible person will publish
the REST API via API publisher. Therefore the REST API would be available
for subscriber / endusers. Once the access token has been generated, user
will be able to access the Registry Resources.
In this mode, There are 2 ways in which I have implemented the REST API
invocation process. This is explained as below.
1 REST client API gateway(REST API published at the APIM)
Registry REST API Registry Resource Response go to REST
client.
The above implementation works fine.
2 REST Client - Registry REST API Call the REST endpoint at
the APIM return call from APIM to Registry REST API Registry
Resource Response back to REST client.
The above approach, I have the an issue to pass the payload from Registry
REST API to APIM. I have designed the REST API in CXF/ JAx-Rs. The apache
CXF Jax-Rs implementation provide a Request Handler which is an interceptor
for the incoming requests. Therefore any request made from REST client to
Registry REST API will hit the Request Handler First.
Therefore, when the request go to the handler, it will check whether the
request comes from APIM or Straight from the Client. If it comes from the
client it will call the REST API endpoint at the APIM via an apache
HttpClient. Therefore when I call it, I have to extract the access token,
queryParam, payload..etc from REST client's request and add it to the
request given to APIM. But I am able to extract the access token,
queryparam and add it to HttpMethod and call the APIM. Request Handler
seems that does not have a way to extract the payload ( POST/PUT).
Therefore unable to pass the payload to the REGISTRY REST API. That is why
GET and DELETE requests are working fine in the second approach since those
do not require the payload. BUT POST/PUT requests fail to proceed.
Therefore The CXF JAX-RS Request Handler has both the Standalone Mode and
APIM mode execution. Therefore the standalone mode is working fine. But
Which approach to be selected regarding the APIM mode to put it in the
request handler class. Since there is an issue in Approach 2 @ APIM mode,
It went to approach 1. According to the approach 1 the code will be cleaner
than approach 2.
*According to Approach 1 @APIM mode the example Request URL will be,*
http://{ipaddress}:8280/{REST API context
@APIM}/{version}/comments?path=/sample.xml.
*in Standalone mode:
*
http:{IP address}:{greg http port}/{rest api context @
greg}/comments?path=/sample.xml.
The APIM team already given their words to derive an integrate able APIM
solution for other WSO2 products. Meanwhile we heard that APIM team working
on that too.
Few days ago, Had a chat with APIM guys, They said that API publisher and
API store will be there as it is. Therefore whoever wants to publish an API
have login to the API publisher and publish an API. This can not be done
automatically during the server starts up.
This is all about the integration part of REST API with API Manager. @APIM
please let us know the current stage of your solution.
Thanks!
Ragu
___
Dev mailing list
d...@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Lakmali Baminiwatta*
*
Software Engineer
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
