[gatein-dev] Permission in Application Registry
Trong Tran
trongtt at gmail.com
Wed May 19 23:16:56 EDT 2010
On 14 May 2010 22:21, Matthew Wringe <mwringe at redhat.com> wrote:
> On Wed, 2010-05-12 at 12:06 +0700, Trong Tran wrote:
> >
> >
> > On 30 April 2010 01:15, Matthew Wringe <mwringe at redhat.com> wrote:
> >
> > On Thu, 2010-04-29 at 14:52 +0700, Trong Tran wrote:
> > >
> > >
> > > On 29 April 2010 10:02, Trong Tran <trongtt at gmail.com>
> > wrote:
> > > Hi Matthew,
> > >
> > > On 29 April 2010 01:58, Matthew Wringe
> > <mwringe at redhat.com>
> > > 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
> -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 ?
Note that if a portlet is not setting any access permission == 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20100520/44efe039/attachment.html
More information about the gatein-dev
mailing list