Hi Lakmali There is a potential security vulnerability if you subscribe all the APIs to a single test application. The above will allow an attacker to invoke APIs which are not visible to him by using a token obtain during try out of another API ( which is visible to him ).
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 <[email protected]> wrote: > Hi Jo, > > On 20 April 2017 at 09:01, Joseph Fonseka <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Fri, Mar 24, 2017 at 10:20 AM, Nuwan Dias <[email protected]> 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 >>>>> 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. >>>>> >>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 23, 2017 at 11:06 PM, Sanjeewa Malalgoda < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 23, 2017 at 7:12 PM, Nuwan Dias <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 23, 2017 at 9:04 PM, Sanjeewa Malalgoda < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 23, 2017 at 12:17 PM, Nuwan Dias <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 23, 2017 at 3:15 PM, Joseph Fonseka < >>>>>>>>>>>> [email protected]> 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 <[email protected]> >>>>>>>>>>>>> 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 the >>>>>>>>>>>>>> person who's developing the API to access it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:59 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 23 March 2017 at 13:46, Joseph Fonseka <[email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Mar 23, 2017 at 1:01 PM, Lakmali Baminiwatta < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes that make sense, but if we automatically subscribe to a >>>>>>>>>>>>>>>> published API it will allow a user ( ie user with creator role >>>>>>>>>>>>>>>> in publisher >>>>>>>>>>>>>>>> ) who may not have subscription permission to invoke an API. >>>>>>>>>>>>>>>> That might be >>>>>>>>>>>>>>>> a security concern based on a company policy. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, this can be a valid concern. In that case we can allow >>>>>>>>>>>>>>> this only for users with publish permissions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Lakmali >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or are we only allowing the test feature in publisher for >>>>>>>>>>>>>>>> specific roles. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Jo >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/ >>>>>>>>>>>>>>>>> mailman/listinfo/architecture >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Lakmali Baminiwatta >>>>>>>>>>>>>>> Associate Technical Lead >>>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>>>> mobile: +94 71 2335936 >>>>>>>>>>>>>>> blog : lakmali.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>>>> >>>>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>>>> email : [email protected] >>>>>>>>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Joseph Fonseka* >>>>>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>>>>> lean.enterprise.middleware >>>>>>>>>>>>> >>>>>>>>>>>>> mobile: +94 772 512 430 >>>>>>>>>>>>> skype: jpfonseka >>>>>>>>>>>>> >>>>>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Nuwan Dias >>>>>>>>>>>> >>>>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>>>> email : [email protected] >>>>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>>>> WSO2 Inc. >>>>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>>>> >>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Nuwan Dias >>>>>>>>>> >>>>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>>>> email : [email protected] >>>>>>>>>> Phone : +94 777 775 729 <077%20777%205729> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Sanjeewa Malalgoda* >>>>>>>>> WSO2 Inc. >>>>>>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>>>>>> >>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Nuwan Dias >>>>>>>> >>>>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>>>> email : [email protected] >>>>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> -- >>>>> *Joseph Fonseka* >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: +94 772 512 430 >>>>> skype: jpfonseka >>>>> >>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmali Baminiwatta > Associate Technical Lead > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > mobile: +94 71 2335936 > blog : lakmali.com > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
