You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Jencks <da...@yahoo.com> on 2006/01/19 00:52:07 UTC
Proposal for changes in portal permissions implementation
I've been looking at the portal permissions and how they are used and
think a few things can be simplified and speeded up. If there are no
objections to this general direction I will prepare an initial patch.
1. FolderPermission duplicates the parseActions method from
PortalResourcePermission, and in fact calls it's copy again. I think
this can be eliminated.
2. PortalResourcePermission.parseActions seems to have some rather
odd code:
if (token.equals(JetspeedActions.VIEW))
mask |= JetspeedActions.MASK_VIEW;
else if (token.equals(JetspeedActions.VIEW) ||
token.equals(JetspeedActions.RESTORE))
mask |= JetspeedActions.MASK_VIEW;
I think this can be simplified.
3. I may not have found all the constructor uses, but I think that
subject should be removed from all the portal permissions. I haven't
found any uses of the constructor including a non-null subject
(although I might have missed some). In addition to the resulting
simplification, I believe the subject has no place in the
permissions. The JACC defined permissions for web and ejb do not
include a subject. JACC does allow for unchecked permissions, which
are difficult to imagine if the permissions involved may include a
subject. I think a generally more satisfactory approach is to rely
on the policy implementation to determine the subject itself.
4. Currently each construction of a portal permission involves
string parsing to decipher an actions string. It looks to me as if
this can occur hundreds of times for a medium sized portal page.
Futhermore, this action string appears to be constructed using ad-hoc
string manipulations in AbstractBaseElement.checkPermissions(String
actions). Similarly, the constraints implementation seems to do an
enormous amount of string comparison to match actions. I think that
this can be entirely converted to integer masks with bitwise
operations. I'd propose to do this in steps, starting with the
permissions and working backwards until I hit the contraints
implementation, then converting it.
5. Some of the constants are duplicated between SecuredResource and
JetspeedActions.
Comments? Would these be seen as improvements to jetspeed and be
likely to be applied?
Many thanks
david jencks
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Proposal for changes in portal permissions implementation
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Jencks wrote:
> I've been looking at the portal permissions and how they are used and
> think a few things can be simplified and speeded up. If there are no
> objections to this general direction I will prepare an initial patch.
>
> Comments? Would these be seen as improvements to jetspeed and be likely
> to be applied?
>
+1 on your changes
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Proposal for changes in portal permissions implementation
Posted by James Liao <ji...@gmail.com>.
I would to +1 as a J2 and Geronimo fan. If there is anything that I could
help, pls tell me.
On 1/19/06, David Le Strat <dl...@yahoo.com> wrote:
>
> +1 as well. I also saw your post regarding JACC on
> the Geronimo list. Looks like you are making some
> progress there.
>
> Regards,
>
> David Le Strat
>
> --- David Jencks <da...@yahoo.com> wrote:
>
> > I've been looking at the portal permissions and how
> > they are used and
> > think a few things can be simplified and speeded up.
> > If there are no
> > objections to this general direction I will prepare
> > an initial patch.
> >
> > 1. FolderPermission duplicates the parseActions
> > method from
> > PortalResourcePermission, and in fact calls it's
> > copy again. I think
> > this can be eliminated.
> >
> > 2. PortalResourcePermission.parseActions seems to
> > have some rather
> > odd code:
> >
> > if
> > (token.equals(JetspeedActions.VIEW))
> > mask |=
> > JetspeedActions.MASK_VIEW;
> > else if
> > (token.equals(JetspeedActions.VIEW) ||
> > token.equals(JetspeedActions.RESTORE))
> > mask |=
> > JetspeedActions.MASK_VIEW;
> > I think this can be simplified.
> >
> > 3. I may not have found all the constructor uses,
> > but I think that
> > subject should be removed from all the portal
> > permissions. I haven't
> > found any uses of the constructor including a
> > non-null subject
> > (although I might have missed some). In addition to
> > the resulting
> > simplification, I believe the subject has no place
> > in the
> > permissions. The JACC defined permissions for web
> > and ejb do not
> > include a subject. JACC does allow for unchecked
> > permissions, which
> > are difficult to imagine if the permissions involved
> > may include a
> > subject. I think a generally more satisfactory
> > approach is to rely
> > on the policy implementation to determine the
> > subject itself.
> >
> > 4. Currently each construction of a portal
> > permission involves
> > string parsing to decipher an actions string. It
> > looks to me as if
> > this can occur hundreds of times for a medium sized
> > portal page.
> > Futhermore, this action string appears to be
> > constructed using ad-hoc
> > string manipulations in
> > AbstractBaseElement.checkPermissions(String
> > actions). Similarly, the constraints implementation
> > seems to do an
> > enormous amount of string comparison to match
> > actions. I think that
> > this can be entirely converted to integer masks with
> > bitwise
> > operations. I'd propose to do this in steps,
> > starting with the
> > permissions and working backwards until I hit the
> > contraints
> > implementation, then converting it.
> >
> > 5. Some of the constants are duplicated between
> > SecuredResource and
> > JetspeedActions.
> >
> > Comments? Would these be seen as improvements to
> > jetspeed and be
> > likely to be applied?
> >
> > Many thanks
> > david jencks
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > jetspeed-dev-unsubscribe@portals.apache.org
> > For additional commands, e-mail:
> > jetspeed-dev-help@portals.apache.org
> >
> >
>
>
> ________________________
> David Le Strat
> Blogging @ http://dlsthoughts.blogspot.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
thanks,
- Jian Liao
Re: Proposal for changes in portal permissions implementation
Posted by David Le Strat <dl...@yahoo.com>.
+1 as well. I also saw your post regarding JACC on
the Geronimo list. Looks like you are making some
progress there.
Regards,
David Le Strat
--- David Jencks <da...@yahoo.com> wrote:
> I've been looking at the portal permissions and how
> they are used and
> think a few things can be simplified and speeded up.
> If there are no
> objections to this general direction I will prepare
> an initial patch.
>
> 1. FolderPermission duplicates the parseActions
> method from
> PortalResourcePermission, and in fact calls it's
> copy again. I think
> this can be eliminated.
>
> 2. PortalResourcePermission.parseActions seems to
> have some rather
> odd code:
>
> if
> (token.equals(JetspeedActions.VIEW))
> mask |=
> JetspeedActions.MASK_VIEW;
> else if
> (token.equals(JetspeedActions.VIEW) ||
> token.equals(JetspeedActions.RESTORE))
> mask |=
> JetspeedActions.MASK_VIEW;
> I think this can be simplified.
>
> 3. I may not have found all the constructor uses,
> but I think that
> subject should be removed from all the portal
> permissions. I haven't
> found any uses of the constructor including a
> non-null subject
> (although I might have missed some). In addition to
> the resulting
> simplification, I believe the subject has no place
> in the
> permissions. The JACC defined permissions for web
> and ejb do not
> include a subject. JACC does allow for unchecked
> permissions, which
> are difficult to imagine if the permissions involved
> may include a
> subject. I think a generally more satisfactory
> approach is to rely
> on the policy implementation to determine the
> subject itself.
>
> 4. Currently each construction of a portal
> permission involves
> string parsing to decipher an actions string. It
> looks to me as if
> this can occur hundreds of times for a medium sized
> portal page.
> Futhermore, this action string appears to be
> constructed using ad-hoc
> string manipulations in
> AbstractBaseElement.checkPermissions(String
> actions). Similarly, the constraints implementation
> seems to do an
> enormous amount of string comparison to match
> actions. I think that
> this can be entirely converted to integer masks with
> bitwise
> operations. I'd propose to do this in steps,
> starting with the
> permissions and working backwards until I hit the
> contraints
> implementation, then converting it.
>
> 5. Some of the constants are duplicated between
> SecuredResource and
> JetspeedActions.
>
> Comments? Would these be seen as improvements to
> jetspeed and be
> likely to be applied?
>
> Many thanks
> david jencks
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@portals.apache.org
>
>
________________________
David Le Strat
Blogging @ http://dlsthoughts.blogspot.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org