On Thu, 2010-05-20 at 10:16 +0700, Trong Tran wrote:
On 14 May 2010 22:21, Matthew Wringe <mwringe(a)redhat.com> 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>
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>
> wrote:
> > Hi Matthew,
> >
> > On 29 April 2010 01:58, Matthew Wringe
> <mwringe(a)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. 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