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 <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
