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
