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 :) > I've seen such websites, but I agree that users might not see it as a nice feature. So Workflow *+ delete* should be fine I think. I think we can still use our permission model for this. Maybe by allowing only 4(read) and 5(read+delete) to others? Thanks, Bhathiya > 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 <071%20306%208779> > > <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. > blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/> > > > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *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/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
