[gatein-dev] Permission in Application Registry
Trong Tran
trongtt at gmail.com
Mon May 24 03:57:48 EDT 2010
2010/5/20 Matthew Wringe <mwringe at redhat.com>
> On Thu, 2010-05-20 at 10:16 +0700, Trong Tran wrote:
> >
> >
> > 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
>
> Yes, it makes sense if the user can't access the portlet it shouldn't be
> taking up space in the page editor.
Actually, we have defined something to work like that in the JIRA issue
http://jira.jboss.org/browse/GTNPORTAL-715. the portlet should take space as
the user can take it into account for other people who can see that
protected component
> This will just confuse people as to
> why they can add the portlet to their dashboard pages but can't see
> them.
>
As i said, this makes sense to prevent the user to newly add protected
portlet
> 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
>
i can reproduce it now and this is considered as a cache issue at UI level.
it means to require a re-login after changing permissions in Application
Registry. we are going to fix it soon
>
>
> 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.
>
yes, we should. i addressed it to
https://jira.jboss.org/jira/browse/GTNPORTAL-1239
>
> 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 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
>
>
>
--
Tran The Trong
eXo Platform SAS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20100524/7a360485/attachment-0001.html
More information about the gatein-dev
mailing list