Re: [Dev] [MB] Moving FE operations to BE
Hi All, We can minimize the FE-BE communication by only moving the methods which require Queue connection to be created. Then there won't be any key shared and exposed to the FE. So basically browseQueue() method move to the BE and once the queue details comes to FE getMsgProperties(), getMsgContentType(), getMessageContentAsString() can be called with those data. I think then the communication overhead will be reduce up to considerable extent. I will consider the other client classes methods also with the same approach. If there is any concern with this approach please post to this thread. Cheers! On Wed, Apr 9, 2014 at 3:32 PM, Suresh Attanayaka sur...@wso2.com wrote: Hi Ishara, I would not agree with your argument regarding the FE-BE communication overhead, afterall most of the time it is just a java call over the local-transport, no http cost at all. For me, consuming the JMS queue from the UI is no different from connecting to the database over JDBC from the UI which is not really our model. Plus, the key shared there is a system key and exposing it over HTTP is not a good idea. It should be shared using the OSGI service instead. On Wed, Apr 9, 2014 at 2:30 PM, Ishara Premadasa ish...@wso2.com wrote: Hi Indika, Your observation is correct that getAccessKey() method is not exposed to all the users, however few clarifications to made is this method is not configured to admin role only. According to the current permission model in carbon we can create new roles and assign permissions to that accordingly. However if you look at the permission tree there is only two MB related permission options named, MB - Add Queue - Queue Details Therefore for a user to perform other queue operations than this, we need to provide admin-- configure permission as shown in image [1] which is the reason getAccessKey() is bound to /permission/admin/configure level. (This is more like for any user to work with MB it needs some admin priviledges )Therefore IMO it would be better if we can add more options to above MB level permissions like Browse Queue etc. so user can be authorized to getAccessKey() by selecting that permission rather than moving the operations into BE. On Wed, Apr 9, 2014 at 11:48 AM, Indika Sampath indi...@wso2.com wrote: Hi All, There is an issue with browsing the queue for users which haven't admin role. The reason is following two methods restricted to the admin role in Axis2 level. - getCurrentUser() - getAccessKey() There is a way to get the current logged user from the session but there is no way to get the access key. org.wso2.carbon.andes.ui.client.QueueBrowserClient creating a queue connection and access the queue from the FE. We need user name and access key to creating queue connection. There might be some security issue with QueueBrowserClient as I and Hasitha had discussion with Suresh on yesterday. Some operations in org.wso2.carbon.andes.ui module needs to move to the BE. I have come up with the following implementation design. Move following methods in the QueueBrowserClient to org.wso2.carbon.andes.core.QueueManagerService and expose as web service via org.wso2.carbon.andes.admin.AndesAdminService. - browseQueue() - closeBrowser() - getMsgContentType() - getMessageContentAsString() When we change like this we need to call the BE four times for each Browse operation and this would be same for publish sample msg, purge queue etc. which we don't necessarily have to go for BE. Wouldn't it be an overhead that we make several FE -- BE calls for a single UI operation each time? Thanks! Ishara [1] https://svn.wso2.org/repos/wso2/people/isharap/permissions_non_admin_user.png But there are another two classes org.wso2.carbon.andes.ui.client.QueueReceiverClient and org.wso2.carbon.andes.ui.client.QueueSenderClient needs do the same thing as I think. Cheers! -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/ -- Ishara Premasada Software Engineer, WSO2 Inc. http://wso2.com/ *Blog : http://isharapremadasa.blogspot.com/ http://isharapremadasa.blogspot.com/Twitter : https://twitter.com/ishadil https://twitter.com/ishadil Mobile : +94 714445832 %2B94%20714445832* -- Suresh Attanayake Senior Software Engineer; WSO2 Inc. http://wso2.com/ Blog : http://sureshatt.blogspot.com/ Web : http://www.ssoarcade.com/ Facebook : https://www.facebook.com/IdentityWorld Twitter : https://twitter.com/sureshatt LinkedIn : http://lk.linkedin.com/in/sureshatt Mobile : +94755012060 Mobile : +016166171172 -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/ ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [MB] Moving FE operations to BE
Hi All, There is an issue with browsing the queue for users which haven't admin role. The reason is following two methods restricted to the admin role in Axis2 level. - getCurrentUser() - getAccessKey() There is a way to get the current logged user from the session but there is no way to get the access key. org.wso2.carbon.andes.ui.client.QueueBrowserClient creating a queue connection and access the queue from the FE. We need user name and access key to creating queue connection. There might be some security issue with QueueBrowserClient as I and Hasitha had discussion with Suresh on yesterday. Some operations in org.wso2.carbon.andes.ui module needs to move to the BE. I have come up with the following implementation design. Move following methods in the QueueBrowserClient to org.wso2.carbon.andes.core.QueueManagerService and expose as web service via org.wso2.carbon.andes.admin.AndesAdminService. - browseQueue() - closeBrowser() - getMsgContentType() - getMessageContentAsString() But there are another two classes org.wso2.carbon.andes.ui.client.QueueReceiverClient and org.wso2.carbon.andes.ui.client.QueueSenderClient needs do the same thing as I think. Cheers! -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/ ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [MB] Moving FE operations to BE
Hi Indika, Your observation is correct that getAccessKey() method is not exposed to all the users, however few clarifications to made is this method is not configured to admin role only. According to the current permission model in carbon we can create new roles and assign permissions to that accordingly. However if you look at the permission tree there is only two MB related permission options named, MB - Add Queue - Queue Details Therefore for a user to perform other queue operations than this, we need to provide admin-- configure permission as shown in image [1] which is the reason getAccessKey() is bound to /permission/admin/configure level. (This is more like for any user to work with MB it needs some admin priviledges )Therefore IMO it would be better if we can add more options to above MB level permissions like Browse Queue etc. so user can be authorized to getAccessKey() by selecting that permission rather than moving the operations into BE. On Wed, Apr 9, 2014 at 11:48 AM, Indika Sampath indi...@wso2.com wrote: Hi All, There is an issue with browsing the queue for users which haven't admin role. The reason is following two methods restricted to the admin role in Axis2 level. - getCurrentUser() - getAccessKey() There is a way to get the current logged user from the session but there is no way to get the access key. org.wso2.carbon.andes.ui.client.QueueBrowserClient creating a queue connection and access the queue from the FE. We need user name and access key to creating queue connection. There might be some security issue with QueueBrowserClient as I and Hasitha had discussion with Suresh on yesterday. Some operations in org.wso2.carbon.andes.ui module needs to move to the BE. I have come up with the following implementation design. Move following methods in the QueueBrowserClient to org.wso2.carbon.andes.core.QueueManagerService and expose as web service via org.wso2.carbon.andes.admin.AndesAdminService. - browseQueue() - closeBrowser() - getMsgContentType() - getMessageContentAsString() When we change like this we need to call the BE four times for each Browse operation and this would be same for publish sample msg, purge queue etc. which we don't necessarily have to go for BE. Wouldn't it be an overhead that we make several FE -- BE calls for a single UI operation each time? Thanks! Ishara [1] https://svn.wso2.org/repos/wso2/people/isharap/permissions_non_admin_user.png But there are another two classes org.wso2.carbon.andes.ui.client.QueueReceiverClient and org.wso2.carbon.andes.ui.client.QueueSenderClient needs do the same thing as I think. Cheers! -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/ -- Ishara Premasada Software Engineer, WSO2 Inc. http://wso2.com/ *Blog : http://isharapremadasa.blogspot.com/ http://isharapremadasa.blogspot.com/Twitter : https://twitter.com/ishadil https://twitter.com/ishadilMobile : +94 714445832* ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [MB] Moving FE operations to BE
Hi Ishara, I would not agree with your argument regarding the FE-BE communication overhead, afterall most of the time it is just a java call over the local-transport, no http cost at all. For me, consuming the JMS queue from the UI is no different from connecting to the database over JDBC from the UI which is not really our model. Plus, the key shared there is a system key and exposing it over HTTP is not a good idea. It should be shared using the OSGI service instead. On Wed, Apr 9, 2014 at 2:30 PM, Ishara Premadasa ish...@wso2.com wrote: Hi Indika, Your observation is correct that getAccessKey() method is not exposed to all the users, however few clarifications to made is this method is not configured to admin role only. According to the current permission model in carbon we can create new roles and assign permissions to that accordingly. However if you look at the permission tree there is only two MB related permission options named, MB - Add Queue - Queue Details Therefore for a user to perform other queue operations than this, we need to provide admin-- configure permission as shown in image [1] which is the reason getAccessKey() is bound to /permission/admin/configure level. (This is more like for any user to work with MB it needs some admin priviledges )Therefore IMO it would be better if we can add more options to above MB level permissions like Browse Queue etc. so user can be authorized to getAccessKey() by selecting that permission rather than moving the operations into BE. On Wed, Apr 9, 2014 at 11:48 AM, Indika Sampath indi...@wso2.com wrote: Hi All, There is an issue with browsing the queue for users which haven't admin role. The reason is following two methods restricted to the admin role in Axis2 level. - getCurrentUser() - getAccessKey() There is a way to get the current logged user from the session but there is no way to get the access key. org.wso2.carbon.andes.ui.client.QueueBrowserClient creating a queue connection and access the queue from the FE. We need user name and access key to creating queue connection. There might be some security issue with QueueBrowserClient as I and Hasitha had discussion with Suresh on yesterday. Some operations in org.wso2.carbon.andes.ui module needs to move to the BE. I have come up with the following implementation design. Move following methods in the QueueBrowserClient to org.wso2.carbon.andes.core.QueueManagerService and expose as web service via org.wso2.carbon.andes.admin.AndesAdminService. - browseQueue() - closeBrowser() - getMsgContentType() - getMessageContentAsString() When we change like this we need to call the BE four times for each Browse operation and this would be same for publish sample msg, purge queue etc. which we don't necessarily have to go for BE. Wouldn't it be an overhead that we make several FE -- BE calls for a single UI operation each time? Thanks! Ishara [1] https://svn.wso2.org/repos/wso2/people/isharap/permissions_non_admin_user.png But there are another two classes org.wso2.carbon.andes.ui.client.QueueReceiverClient and org.wso2.carbon.andes.ui.client.QueueSenderClient needs do the same thing as I think. Cheers! -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/ -- Ishara Premasada Software Engineer, WSO2 Inc. http://wso2.com/ *Blog : http://isharapremadasa.blogspot.com/ http://isharapremadasa.blogspot.com/Twitter : https://twitter.com/ishadil https://twitter.com/ishadil Mobile : +94 714445832 %2B94%20714445832* -- Suresh Attanayake Senior Software Engineer; WSO2 Inc. http://wso2.com/ Blog : http://sureshatt.blogspot.com/ Web : http://www.ssoarcade.com/ Facebook : https://www.facebook.com/IdentityWorld Twitter : https://twitter.com/sureshatt LinkedIn : http://lk.linkedin.com/in/sureshatt Mobile : +94755012060 Mobile : +016166171172 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
