My idea was different, "Can anyone point me any site/forum which allow you to edit others comment(*not* approve/reject or *delete entire comment*)". Delete entire comment support need to be their definitely. No doubt about that.
Thanks, sanjeewa. On Fri, May 19, 2017 at 12:01 PM, Fazlan Nazeem <[email protected]> wrote: > Hi Sanjeewa, > > In facebook, if someone posts a comment on our post, then we have the > permission to delete that comment even though that comment was not created > by us. > > In a similar manner, shouldn't we at least support delete comment > permission to a moderator role(api owner or a configurable moderator role)? > > On Fri, May 19, 2017 at 11:22 AM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> Can anyone point me any site/forum which allow you to edit others >> comment(not approve/reject or delete entire comment). I'm just curious :) >> Think what will happen when someone comment on your blogs, media etc(or >> even you can think of product comments of most common e commerce >> platforms). It will go through approval process or filter and then publish. >> >> If we allow someone to edit others comments its a crime IMO :). Hence -1 >> for let someone to edit/update others comment. >> >> Thanks, >> sanjeewa. >> >> >> >> >> On Fri, May 19, 2017 at 11:04 AM, Nuwan Dias <[email protected]> wrote: >> >>> I think standard forums allow privileged users to moderate comments. >>> Moderation can be in the form of approving/rejecting comments or in the >>> form of removing obscene type of comments. >>> >>> If we go down the workflow (approval) path, there's much to implement. >>> Ex: We need to introduce a "state" to the comment, need to implement a >>> workflow, a callback mechanism, a workflow cleanup, etc. But if we just >>> write a piece of code which allows a pre-configured role to remove, edit >>> comments, I think the implementation is much simpler. >>> >>> On Fri, May 19, 2017 at 10:52 AM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, May 19, 2017 at 10:43 AM, Bhathiya Jayasekara < >>>> [email protected]> wrote: >>>> >>>>> Hi Sanjeewa, >>>>> >>>>> On Thu, May 18, 2017 at 5:09 PM, Sanjeewa Malalgoda <[email protected] >>>>> > wrote: >>>>> >>>>>> I don't think its worth to get complete permission model for comments >>>>>> as well. Like bhathiya mentioned only comment owner is allowed to >>>>>> update/delete his comment. That is the normal behavior. Also i feel its >>>>>> better if we can have work flow support for comments(by default this need >>>>>> to disabled). Once something posted if we let someone else to modify its >>>>>> not nice. >>>>>> >>>>> >>>>> Admin or similar role might be needing moderator capability for >>>>> comments. WDYT? To support that we can easily use existing permission >>>>> model. >>>>> >>>> I haven't see a single website or forum which allows one person to edit >>>> others comments. We cannot edit or update any others comment :) Its not >>>> Only thing admin or other person can do is approve/reject comment or delete >>>> it. It means workflow + delete permission to only super user. WDYT? >>>> >>>> Thanks, >>>> sanjeewa. >>>> >>>> >>>>> Thanks, >>>>> Bhathiya >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> sanjeewa. >>>>>> >>>>>> On Thu, May 18, 2017 at 11:20 AM, Fazlan Nazeem <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Nuwan/Bhathiya, >>>>>>> >>>>>>> On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <[email protected]> wrote: >>>>>>> >>>>>>>> I think what Bhathiya is suggesting is to bring in our usual >>>>>>>> permissions model (in APIM 3.0.0) to comments as well. This will >>>>>>>> require >>>>>>>> more data to be saved in the DB but will address the issue at hand. >>>>>>>> >>>>>>>> >>>>>>> Are you suggesting we should have an extra column in Comments table >>>>>>> in the db to fulfill this? >>>>>>> >>>>>>> I am thinking of using the AM_API_PERMISSION column introduced in >>>>>>> AM_API table to decide on who can update/delete a specific comment. >>>>>>> Apart >>>>>>> from the user who commented, If a user can delete or update an API he >>>>>>> can >>>>>>> delete/update any comment for that API. This way we do not need to save >>>>>>> extra information in the db, and can use the api permission information >>>>>>> to >>>>>>> control the comment actions. >>>>>>> >>>>>>> There are two levels of permissions required here. One is "who can >>>>>>>> add/update/remove comments in general" and the other is "whose >>>>>>>> comments can >>>>>>>> I update/remove". >>>>>>>> >>>>>>>> The first can be simply achieved using scopes. Basically say which >>>>>>>> scope is permitted for the /comments API. The second can be solved by >>>>>>>> using >>>>>>>> our usual permission model in APIM v3.0.0. >>>>>>>> >>>>>>>> On Tue, May 9, 2017 at 10:10 AM, Ayyoob Hamza <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This won't tackle the problem Musthaq suggested which requires >>>>>>>>> validation in the backend. >>>>>>>>> >>>>>>>>> *Ayyoob Hamza* >>>>>>>>> *Senior Software Engineer* >>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>>>>> >>>>>>>>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We had a similar requirement to have a fine grained access for >>>>>>>>>> users in IoTS and we went with the approach of assigning permission >>>>>>>>>> for >>>>>>>>>> scope rather than roles. >>>>>>>>>> >>>>>>>>>> *Ayyoob Hamza* >>>>>>>>>> *Senior Software Engineer* >>>>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>>>> email: [email protected] cell: +94 77 1681010 >>>>>>>>>> <%2B94%2077%207779495> >>>>>>>>>> >>>>>>>>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Prasanna/Pubudu, >>>>>>>>>>> >>>>>>>>>>> I think if we use scope based validation there will be an issue >>>>>>>>>>> here. Lets take the same example. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>>>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} - >>>>>>>>>>> comment-delete-scopeUPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>> - >>>>>>>>>>> comment-update-scope* >>>>>>>>>>> >>>>>>>>>>> Scope and roles matching are as follows. >>>>>>>>>>> >>>>>>>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>>>>>>> *comment-**update**-scope : **subscriber-role, **admin-role* >>>>>>>>>>> *comment-delete-scope : **admin-role* >>>>>>>>>>> >>>>>>>>>>> Lets say there are two store users *A* and *B* who have the >>>>>>>>>>> *subscriber-role. >>>>>>>>>>> *And user *A* adds a comment to an API (*comment-add-scope*). >>>>>>>>>>> Then user *B *logs in and he will be able to update that >>>>>>>>>>> particular comment which user *A *has added since user *B *has >>>>>>>>>>> the *subscriber-role* too. >>>>>>>>>>> >>>>>>>>>>> IMO this should not be allowed. AFAIC we might have to go with >>>>>>>>>>> user validation. >>>>>>>>>>> If we can get the logged in user's roles and if that user has >>>>>>>>>>> admin-role or that particular comment is added by the logged in >>>>>>>>>>> user we can >>>>>>>>>>> allow this user to update or delete the comment. WDYT? >>>>>>>>>>> >>>>>>>>>>> Thanks & Regards, >>>>>>>>>>> Mushthaq >>>>>>>>>>> >>>>>>>>>>> On Tue, May 9, 2017 at 6:31 AM, Prasanna Dangalla < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Fazlan, >>>>>>>>>>>> >>>>>>>>>>>> I think as Ishara and Pubudu have mentioned we can use the >>>>>>>>>>>> scope validation. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 9, 2017 at 12:03 AM, Pubudu Gunatilaka < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> + Adding architecture mail group >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Fazlan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As Ishara mentioned above, we can do this with scope >>>>>>>>>>>>>> validation. Each and every resource has a scope. The scope is >>>>>>>>>>>>>> associated >>>>>>>>>>>>>> with one or more roles. Consider the following example. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Resource and scope matching are as follows. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>>>>>>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>> - >>>>>>>>>>>>>> comment-manage-scopeUPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>> - >>>>>>>>>>>>>> comment-manage-scope* >>>>>>>>>>>>>> >>>>>>>>>>>>>> Scope and roles matching are as follows. >>>>>>>>>>>>>> >>>>>>>>>>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>>>>>>>>>> *comment-manage-scope : admin-role* >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> @Pubudu: >>>>>>>>>>>> >>>>>>>>>>>> IMO a person who adds a comment should have the UPDATE >>>>>>>>>>>> privilege as well. DELETE can be restricted to admin. Like wise we >>>>>>>>>>>> might >>>>>>>>>>>> find many combinations with different use cases. So I think its >>>>>>>>>>>> better to >>>>>>>>>>>> decouple this *comment-manage-scope *to two different scopes >>>>>>>>>>>> as >>>>>>>>>>>> *comment-update-scope *and *comment-delete-scope. *If we do >>>>>>>>>>>> this, we can assign it to respective roles in scope and role >>>>>>>>>>>> mapping for >>>>>>>>>>>> different use cases. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Prasanna >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> When a user hits the GET resource we can do the following. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Retrieve the scope of the resource >>>>>>>>>>>>>> 2. Retrieve the roles of the scope >>>>>>>>>>>>>> 3. Validate the user based on the role and allow or deny the >>>>>>>>>>>>>> request. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thank you! >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, May 8, 2017 at 5:04 PM, Fazlan Nazeem < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> How about introducing scope based permission model? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can define scope for each resource and validate against >>>>>>>>>>>>>>>> the logged in user scopes. >>>>>>>>>>>>>>>> This way we can let the admin to edit the scope so that he >>>>>>>>>>>>>>>> can fine grain the access to these resources. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My understanding is, with scopes what we can decide is >>>>>>>>>>>>>>> whether a particular user has access to hit an API resource >>>>>>>>>>>>>>> URL. In my >>>>>>>>>>>>>>> example all users with subscriber scope will have access to hit >>>>>>>>>>>>>>> the api, >>>>>>>>>>>>>>> but the question is, out of those subscribers how do we choose >>>>>>>>>>>>>>> the right >>>>>>>>>>>>>>> subscriber for the right action. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>>> Ishara Cooray >>>>>>>>>>>>>>>> Senior Software Engineer >>>>>>>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>>>>>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:42 PM, Fazlan Nazeem < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is about how we should handle access permission for >>>>>>>>>>>>>>>>> subresources in api store. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Parent Resource Access * >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Consider the following REST calls. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> GET /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>>>> GET apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At the moment we are not checking whether a particular >>>>>>>>>>>>>>>>> user has read access to the specific api before we retrieve >>>>>>>>>>>>>>>>> the requested >>>>>>>>>>>>>>>>> comment or document. Is it fine to ignore this check for >>>>>>>>>>>>>>>>> these apis >>>>>>>>>>>>>>>>> assuming that a user might be already having read access to >>>>>>>>>>>>>>>>> the api because >>>>>>>>>>>>>>>>> he already knows the uuid of the api? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Or should we be doing an explicit permission validation? >>>>>>>>>>>>>>>>> Do we have any drawbacks in doing this check? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Subresource Update/Delete* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Consider the following REST api calls done by a user in >>>>>>>>>>>>>>>>> store. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DELETE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>>>> UPDATE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DELETE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>>>> UPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> In order to restrict who can update and delete these >>>>>>>>>>>>>>>>> subresources, we can pass the username to DAO layer and check >>>>>>>>>>>>>>>>> who created >>>>>>>>>>>>>>>>> it, and allow only that person to do these modifications. But >>>>>>>>>>>>>>>>> there could >>>>>>>>>>>>>>>>> be a use-case where another user(admin) will need to delete >>>>>>>>>>>>>>>>> or update a >>>>>>>>>>>>>>>>> resource created by someone else. If we restrict only the >>>>>>>>>>>>>>>>> creator to do >>>>>>>>>>>>>>>>> these actions, then we cannot support such a use-case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Appreciate your thoughts on this. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>>> Software Engineer >>>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Architecture mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Mushthaq Rumy >>>>>>>>>>> *Software Engineer* >>>>>>>>>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194> >>>>>>>>>>> Email : [email protected] >>>>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>>>> lean . enterprise . middleware. >>>>>>>>>>> >>>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks & Regards, >>>>>>> >>>>>>> Fazlan Nazeem >>>>>>> >>>>>>> *Senior Software Engineer* >>>>>>> >>>>>>> *WSO2 Inc* >>>>>>> Mobile : +94772338839 >>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>> [email protected] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 <071%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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Bhathiya Jayasekara* >>>>> *Associate Technical Lead,* >>>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>>> >>>>> *Phone: +94715478185 <071%20547%208185>* >>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>>> <http://www.linkedin.com/in/bhathiyaj>* >>>>> *Twitter: https://twitter.com/bhathiyax >>>>> <https://twitter.com/bhathiyax>* >>>>> *Blog: http://movingaheadblog.blogspot.com >>>>> <http://movingaheadblog.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/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 <071%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 >> >> > > > -- > Thanks & Regards, > > Fazlan Nazeem > > *Senior Software Engineer* > > *WSO2 Inc* > Mobile : +94772338839 > <%2B94%20%280%29%20773%20451194> > [email protected] > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <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
