Hi Matthew, On 29 April 2010 01:58, Matthew Wringe <mwringe(a)redhat.com&gt; wrote: > I created https://jira.jboss.org/jira/browse/GTNPORTAL-1137 but it seems > like it might be somewhat working depending on what it actually means. > > What is the permission setting in application registry suppose to do > actually do? Is it suppose to prevent a user from accessing the content > or to prevent a user from adding that type of portlet to a page? > It prevents a user from accessing the content > > Each portlet or gadget can specify a 'access permission', but this > doesn't seem to prevent users from viewing the application. > > What it does seem to do is if an unauthorized user tries to add this > portlet to a page, they can add the portlet, they just can't view the > added portlet on the page. This doesn't seem like expected behaviour > either. > now this behaviour is expected actually except we re-define clearly what it should be About the GTNPORTAL-1137 : +* I can change the permission of a portlet and still have an unauthorized user view its content*. This is considered as a bug and we are checking it

+ *It does seem to prevent a user from viewing a gadget as a portlet on the dashboard page, but they can still add the gadget as a gadget to the dashboard page*. This behaviour is expected too except we re-define it :-) > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > -- Tran The Trong eXo Platform SAS

On Thu, 2010-04-29 at 14:52 +0700, Trong Tran wrote: > > > On 29 April 2010 10:02, Trong Tran <trongtt(a)gmail.com&gt; wrote: > Hi Matthew, > > On 29 April 2010 01:58, Matthew Wringe <mwringe(a)redhat.com&gt; > wrote: > I created > https://jira.jboss.org/jira/browse/GTNPORTAL-1137 but > it seems > like it might be somewhat working depending on what it > actually means. > > What is the permission setting in application registry > suppose to do > actually do? Is it suppose to prevent a user from > accessing the content > or to prevent a user from adding that type of portlet > to a page? > > It prevents a user from accessing the content > > > Each portlet or gadget can specify a 'access > permission', but this > doesn't seem to prevent users from viewing the > application. > > What it does seem to do is if an unauthorized user > tries to add this > portlet to a page, they can add the portlet, they just > can't view the > added portlet on the page. This doesn't seem like > expected behaviour > either. > > now this behaviour is expected actually except we re-define > clearly what it should be The only problem I see with this is that the user probably shouldn't be able to see the portlet to add to the page. The fact that when the unauthorized user adds the portlet to the page, and then cannot access the portlet on the page does seem to be correct behavior.

The problem is what root creates a page, adds a portlet to it and then unauthorized users can still access it. > About the GTNPORTAL-1137 : > + I can change the permission of a portlet and still have an > unauthorized user view its content. This is considered as a > bug and we are checking it > > > i can not reproduce it. in my test, the unauthorized user can not view > the content of a portlet if its access permission is set up Are you following the steps in the jira? please note that I am talking about changing the access permission of the portlet (ie set in the app registry) not changing the permission of a particular portlet instance on a page.

> + It does seem to prevent a user from viewing a gadget as a > portlet on the dashboard page, but they can still add the > gadget as a gadget to the dashboard page. This behaviour is > expected too except we re-define it :-) I think we should have some sort of gadget permission settings for the dashboard, and we should also see if we can restrict gadget access from outside sources. The gadget xml files are publicly available for anyone to access. Even if we could restrict what gadget a user can put on the dashboard, they could just add the gadget back using the gadget url. > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > > -- > Tran The Trong > eXo Platform SAS > > > > > -- > Tran The Trong > eXo Platform SAS

On Wed, 2010-05-12 at 12:06 +0700, Trong Tran wrote: > > > On 30 April 2010 01:15, Matthew Wringe <mwringe(a)redhat.com&gt; wrote: > > On Thu, 2010-04-29 at 14:52 +0700, Trong Tran wrote: > > > > > > On 29 April 2010 10:02, Trong Tran <trongtt(a)gmail.com&gt; > wrote: > > Hi Matthew, > > > > On 29 April 2010 01:58, Matthew Wringe > <mwringe(a)redhat.com&gt; > > wrote: > > I created > > > https://jira.jboss.org/jira/browse/GTNPORTAL-1137 but > > it seems > > like it might be somewhat working depending > on what it > > actually means. > > > > What is the permission setting in > application registry > > suppose to do > > actually do? Is it suppose to prevent a user > from > > accessing the content > > or to prevent a user from adding that type > of portlet > > to a page? > > > > It prevents a user from accessing the content > > > > > > Each portlet or gadget can specify a 'access > > permission', but this > > doesn't seem to prevent users from viewing > the > > application. > > > > What it does seem to do is if an > unauthorized user > > tries to add this > > portlet to a page, they can add the portlet, > they just > > can't view the > > added portlet on the page. This doesn't seem > like > > expected behaviour > > either. > > > > now this behaviour is expected actually except we > re-define > > clearly what it should be > > > The only problem I see with this is that the user probably > shouldn't be > able to see the portlet to add to the page. > > The fact that when the unauthorized user adds the portlet to > the page, > and then cannot access the portlet on the page does seem to be > correct > behavior. > > Yes, i agreed that user should not be able to add a portlet to the > page if he does not have access permission to that portlet > > > The problem is what root creates a page, adds a portlet to it > and then > unauthorized users can still access it. > > > About the GTNPORTAL-1137 : > > + I can change the permission of a portlet and still > have an > > unauthorized user view its content. This is > considered as a > > bug and we are checking it > > > > > > i can not reproduce it. in my test, the unauthorized user > can not view > > the content of a portlet if its access permission is set up > > > Are you following the steps in the jira? > > please note that I am talking about changing the access > permission of > the portlet (ie set in the app registry) not changing the > permission of > a particular portlet instance on a page. > > changing the access permission in Application Registry does not affect > to its existing portlet instance I am still confused over what is happening here and what the designed behaviour is suppose to be. What I would expect the access permission in the application registry to do is to set the permission at the portlet level (not portlet instance level). This permission would override any portlet instance access permission. So each portlet would need to have both permissions be valid before allowing access to the portlet. So if I have my portal setup and I decide that a particular portlet should only be view by a specific group of people, then I set that permission in the application registry and all portlet instances should only be accesible by that group. I shouldn't need to go through all the portlet instances and manually change their permissions (and then periodically go through and check permissions to make sure nothing has changed or if a new instance has been added with the wrong permission). We need per portlet access permissions. It sounds like this is not how its suppose to work, and that it was designed to work in another manner. We need to at least change the wording in the application registry page to something other than 'access permission', its dangerous to use that term here when it doesn't prevent user access to that particular portlet. How is it suppose to work right now? -Is this meant to prevent a group from adding this particular portlet to a page? (currently doesn't do this, if I set the portlet's access permission in public, users still can't see it).

-Is it meant to set the default permission of a portlet instance when added to a page (also doesn't do this, the default access permission for a portlet instance is set to public).

I am trying to figure out the designed behaviour before opening jiras about these issues. > > > + It does seem to prevent a user from viewing a > gadget as a > > portlet on the dashboard page, but they can still > add the > > gadget as a gadget to the dashboard page. This > behaviour is > > expected too except we re-define it :-) > > > I think we should have some sort of gadget permission settings > for the > dashboard, and we should also see if we can restrict gadget > access from > outside sources. The gadget xml files are publicly available > for anyone > to access. > Even if we could restrict what gadget a user can put on the > dashboard, > they could just add the gadget back using the gadget url. > > > > > > > _______________________________________________ > > gatein-dev mailing list > > gatein-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > > > > > > > -- > > Tran The Trong > > eXo Platform SAS > > > > > > > > > > -- > > Tran The Trong > > eXo Platform SAS > > > > > > > -- > Tran The Trong > eXo Platform SAS

On Thu, 2010-05-20 at 10:16 +0700, Trong Tran wrote: > > > On 14 May 2010 22:21, Matthew Wringe <mwringe(a)redhat.com&gt; wrote: > > On Wed, 2010-05-12 at 12:06 +0700, Trong Tran wrote: > > > > > > On 30 April 2010 01:15, Matthew Wringe <mwringe(a)redhat.com&gt; > wrote: > > > > On Thu, 2010-04-29 at 14:52 +0700, Trong Tran wrote: > > > > > > > > > On 29 April 2010 10:02, Trong Tran > <trongtt(a)gmail.com&gt; > > wrote: > > > Hi Matthew, > > > > > > On 29 April 2010 01:58, Matthew Wringe > > <mwringe(a)redhat.com&gt; > > > wrote: > > > I created > > > > > https://jira.jboss.org/jira/browse/GTNPORTAL-1137 > but > > > it seems > > > like it might be somewhat working > depending > > on what it > > > actually means. > > > > > > What is the permission setting in > > application registry > > > suppose to do > > > actually do? Is it suppose to > prevent a user > > from > > > accessing the content > > > or to prevent a user from adding > that type > > of portlet > > > to a page? > > > > > > It prevents a user from accessing the > content > > > > > > > > > Each portlet or gadget can specify > a 'access > > > permission', but this > > > doesn't seem to prevent users from > viewing > > the > > > application. > > > > > > What it does seem to do is if an > > unauthorized user > > > tries to add this > > > portlet to a page, they can add > the portlet, > > they just > > > can't view the > > > added portlet on the page. This > doesn't seem > > like > > > expected behaviour > > > either. > > > > > > now this behaviour is expected actually > except we > > re-define > > > clearly what it should be > > > > > > The only problem I see with this is that the user > probably > > shouldn't be > > able to see the portlet to add to the page. > > > > The fact that when the unauthorized user adds the > portlet to > > the page, > > and then cannot access the portlet on the page does > seem to be > > correct > > behavior. > > > > Yes, i agreed that user should not be able to add a portlet > to the > > page if he does not have access permission to that portlet > > > > > > The problem is what root creates a page, adds a > portlet to it > > and then > > unauthorized users can still access it. > > > > > About the GTNPORTAL-1137 : > > > + I can change the permission of a portlet > and still > > have an > > > unauthorized user view its content. This > is > > considered as a > > > bug and we are checking it > > > > > > > > > i can not reproduce it. in my test, the > unauthorized user > > can not view > > > the content of a portlet if its access permission > is set up > > > > > > Are you following the steps in the jira? > > > > please note that I am talking about changing the > access > > permission of > > the portlet (ie set in the app registry) not > changing the > > permission of > > a particular portlet instance on a page. > > > > changing the access permission in Application Registry does > not affect > > to its existing portlet instance > > > I am still confused over what is happening here and what the > designed > behaviour is suppose to be. > > What I would expect the access permission in the application > registry to > do is to set the permission at the portlet level (not portlet > instance > level). This permission would override any portlet instance > access > permission. So each portlet would need to have both > permissions be valid > before allowing access to the portlet. > So if I have my portal setup and I decide that a particular > portlet > should only be view by a specific group of people, then I set > that > permission in the application registry and all portlet > instances should > only be accesible by that group. > I shouldn't need to go through all the portlet instances and > manually > change their permissions (and then periodically go through and > check > permissions to make sure nothing has changed or if a new > instance has > been added with the wrong permission). > We need per portlet access permissions. > > It sounds like this is not how its suppose to work, and that > it was > designed to work in another manner. We need to at least change > the > wording in the application registry page to something other > than 'access > permission', its dangerous to use that term here when it > doesn't prevent > user access to that particular portlet. > > How is it suppose to work right now? > -Is this meant to prevent a group from adding this particular > portlet to > a page? (currently doesn't do this, if I set the portlet's > access > permission in public, users still can't see it). > > Currently No, it is not. But it makes sense to change this behaviour Yes, it makes sense if the user can't access the portlet it shouldn't be taking up space in the page editor.

This will just confuse people as to why they can add the portlet to their dashboard pages but can't see them.

I don't know if this is currently working or not as changing a portlet to be public still doesn't make that portlet appear to users in their dashboards. > > -Is it meant to set the default permission of a portlet > instance when > added to a page (also doesn't do this, the default access > permission for > a portlet instance is set to public). > > Yes, it is. doesn't it work for you ? no it doesn't work for me, it always makes the permission public regardless of what the permission of the portlet actually is. I have updated the original jira with this information http://jira.jboss.org/browse/GTNPORTAL-1137

Note that if a portlet is not setting any access permission == Public ok, why don't we just set the portlet to be public in the first place? Its confusing that the default access permission in the application registry is not set to public, yet this is assumed to be the default state.

Also, we should change the wording in the application registry for this to make it clear what its meant to do. (http://jira.jboss.org/browse/GTNPORTAL-1229) > > I am trying to figure out the designed behaviour before > opening jiras > about these issues. > > > > > > > + It does seem to prevent a user from > viewing a > > gadget as a > > > portlet on the dashboard page, but they > can still > > add the > > > gadget as a gadget to the dashboard page. > This > > behaviour is > > > expected too except we re-define it :-) > > > > > > I think we should have some sort of gadget > permission settings > > for the > > dashboard, and we should also see if we can restrict > gadget > > access from > > outside sources. The gadget xml files are publicly > available > > for anyone > > to access. > > Even if we could restrict what gadget a user can put > on the > > dashboard, > > they could just add the gadget back using the gadget > url. > > > > > > > > > > > > _______________________________________________ > > > gatein-dev mailing list > > > gatein-dev(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/gatein-dev > > > > > > > > > > > > > > > -- > > > Tran The Trong > > > eXo Platform SAS > > > > > > > > > > > > > > > -- > > > Tran The Trong > > > eXo Platform SAS > > > > > > > > > > > > > > -- > > Tran The Trong > > eXo Platform SAS > > > > > > > > -- > Tran The Trong > eXo Platform SAS