Hi, While implementing the feature we have this permission problem w:r:t permission tree. We want to restrict following two operations
>> subscription browse >> subscription close (this new feature) Following are possible permission scenarios 1. One should be able to browse without close permission 2. To be able to close subscription, user must have browse permission (close button is in browse page) Currently we cannot cater for this requirement. We cannot de-select "Close" when "Queue" is selected (browse permission given by "Queue") Please consider following image [image: Inline image 1] Is there any better way to do this other than using same level permissions for subscription browse and subscriptions close (no dependency can be enforced)? Thanks On Thu, Dec 3, 2015 at 7:10 PM, Frank Leymann <[email protected]> wrote: > +1 > I would even say stronger "...we MUST give a way..." > > > Best regards, > Frank > > 2015-12-03 11:01 GMT+01:00 Srinath Perera <[email protected]>: > >> If the user must go to the node where subscription is made to disconnect >> the subscription, we might need to give a way for a user to find which node >> has what subscriptions. >> >> --Srinath >> >> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe <[email protected]> >> wrote: >> >>> I propose, >>> 1) user cant disconnect consumers in another nodes. ( simplifies the >>> approach). >>> 2) there need to be a permission around it. >>> 3) it could for any subscriber ( may be lets leave out MQTT for a bit) >>> whose misbehaving. >>> >>> >>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva <[email protected]> >>> wrote: >>> >>>> Hi Hasitha, >>>> >>>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to >>>> implement this feature for MQTT for now. We can consider it when >>>> implementing MQTT UI in our major release. WDYT? >>>> >>>> Thank you, >>>> Sajini >>>> >>>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> There is a feature request that Message Broker should support to >>>>> forcefully disconnect a subscriber. This means, server should be able to >>>>> disconnect misbehaving subscribers. Server has a control over it. >>>>> >>>>> Steps to do this would be >>>>> >>>>> 1. Find a way to disconnect the socket from mina transport level. >>>>> 2. Send a message to Andes core to delete (disconnect) the subscriber. >>>>> >>>>> At step two the node that is disconnecting the socket, will broadcast >>>>> a Hazelcast message that this subscriber is closed. >>>>> >>>>> With above implementation steps, a limitation is introduced as "you >>>>> can only disconnect the subscribers originated to that node only". For >>>>> example, say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 >>>>> and >>>>> sub2 for MB2. You need to go to MB1's web console to disconnect sub1 and >>>>> MB2's web console to disconnect sub2. So cluster aspect is lost there. >>>>> >>>>> Thus two implementation approaches are there >>>>> >>>>> 1. Forceful disconnection can be done only from the node subscriber is >>>>> connected to. >>>>> 2. Forceful disconnection can be done from any node (this is bit >>>>> complex. Involves Hazelcast notifications) >>>>> >>>>> As our end goal for implementation would option 1 be adequate? >>>>> Or do we need to reach out for option 2 as well? >>>>> Do we need to facilitate this for any subscription type >>>>> (queue/topic/durable topic/shared durable topic) ? What about MQTT >>>>> subscribers? >>>>> >>>>> Also what are the permissions a user should have to perform this >>>>> action? Are we going to introduce a new permission type? >>>>> >>>>> Thanks >>>>> -- >>>>> *Hasitha Abeykoon* >>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com >>>>> *cell:* *+94 719363063* >>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sajini De SIlva >>>> Software Engineer; WSO2 Inc.; http://wso2.com , >>>> Email: [email protected] >>>> Blog: http://sajinid.blogspot.com/ >>>> Git hub profile: https://github.com/sajinidesilva >>>> >>>> Phone: +94 712797729 >>>> >>>> >>> >>> >>> -- >>> Ramith Jayasinghe >>> Technical Lead >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> E: [email protected] >>> P: +94 777542851 >>> >>> >> >> >> -- >> ============================ >> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >> Site: http://people.apache.org/~hemapani/ >> Photos: http://www.flickr.com/photos/hemapani/ >> Phone: 0772360902 >> >> _______________________________________________ >> 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 > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
