2010/5/20 Matthew Wringe <mwringe@redhat.com>
On Thu, 2010-05-20 at 10:16 +0700, Trong Tran wrote:
>
>
> On 14 May 2010 22:21, Matthew Wringe <mwringe@redhat.com> wrote:
>
>         On Wed, 2010-05-12 at 12:06 +0700, Trong Tran wrote:
>         >
>         >
>         > On 30 April 2010 01:15, Matthew Wringe <mwringe@redhat.com>
>         wrote:
>         >
>         >         On Thu, 2010-04-29 at 14:52 +0700, Trong Tran wrote:
>         >         >
>         >         >
>         >         > On 29 April 2010 10:02, Trong Tran
>         <trongtt@gmail.com>
>         >         wrote:
>         >         >         Hi Matthew,
>         >         >
>         >         >         On 29 April 2010 01:58, Matthew Wringe
>         >         <mwringe@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@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