On Sep 1, 2009, at 7:54 AM, Ate Douma wrote:
David Sean Taylor wrote:
Would anyone object to me moving the Permission classes
(FolderPermission, PortletPermission, BaseJetspeedPermission
etc...) back into /jetspeed-commons ? I cannot find a way to
easily extend the permission system, something I could easily do in
2.1.3.
For example, from a portlet I would like to do a permission check
from a portlet:
try
{
// use standard Java security to do a permission check
using the seed configuration
AccessController.checkPermission(new
ContactPermission(contact.getID(), "view"));
}
catch (Throwable t)
{
isContactViewable = false;
}
But I have to derive my ContactPermission from
BaseJetspeedPermission, living in the security jar
I am stuck right now with a 2.1.3 portal using AccountPermissions
that won't port to 2.2, as well as the Contact example above in
another new portal.
Hi David,
The Permission classes, just as our Security Principal classes, were
drastically refactored to get rid of the many "wrapped" layers in
the 2.1.x security model.
Permissions are a peculiar beast as they need to extend both the
java.security.Permission abstract class as well as be mapped on(or
preferably extend) persistent capable classes to be able to store
them in the database.
Without falling back into the old 2.1.x "trap" of creating another
wrapping or marshaling/unmarshaling solution this was difficult to
implement other than switching to a single public interface
(JetspeedPermission) and having to define specific/extended
Permission classes within the security component (spi) package.
Creating a new Permission instance now is delegated to, and thereby
controlled by, the new PermissionManager factory methods
like .newPermission(String type. String name, String actions).
Creating/instantiating new Permission types like ContactPermission
in the new solution indeed will require adding a new
ContactPermissionImpl extending BaseJetspeedPermission in the portal
context (e.g. same classpath as the security-component itself).
You can of course optionally have it implement an interface like a
ContactPermission if needed.
When setup like this, the following could then be an example rewrite
of your example above:
AccessController
.checkPermission(permissionManager.newPermission("contact",
contact.getID().toString, "view"));
I know all this requires a little bit more work then before but
AFAIK not *much* more.
This is perfect. My bad, I overlooked the newPermission interface in
the base factory class. (be nice if the interfaces had javadocs, im as
guilty of this interface as anyone...)
Only major difference is the need to provide these Permission
classes within the portal classpath, not the shared classpath.
I suppose(d) the usage of these would be in the portal (security)
context anyway, but maybe I'm wrong there.
If you see major problems for converting your 2.1.3 configuration
over to the new model I'd like to help out and see if I can come up
with a solution. If it really turns out to be problematic, of course
we'll have to find a different solution. And, if necessary, even
move these base classes back into jetspeed-commons.
But then we'll have to go back again to a wrapping and marshalling/
unmarshalling solution for persistence as well.
Additionally, I can only add permission/actions in my seed data
that are validated by JetspeedAction's valid window states or
portlet modes.
I will have to look deeper into this. Could be we still have some
loose ends there.
Furthermore, for modes like "config" the actions *still* seem to be
failing when loaded from permission-seed-data.
OK, can you provide me more details?
I'd like to help out and see if we can solve this.
Simply working from the trunk, edit j2-seed.xml and and then do a
target=demo build and you will see the error. For example:
<Permission type="portal" resource="rss::*" actions="view, edit,
someAction">
or even an extended mode:
<Permission type="portal" resource="rss::*" actions="view, edit,
config">
The build will error out complaining about an undefined action. I've
created a JIRA issue, doesn't matter who works on it, I can get to it
too
I would like to propose:
1. moving BaseJetspeedPermission and its derived classes to commons
Please see above.
I'm not against it, but I'd like to review first if the current
solution cannot be used after all, possibly with some improvements.
No. Your solution works for me. People who are providing their own
permission classes will have to either drop them in the common class
loader or in Jetspeed's class loader
2. being more lenient on actions (allow any valid string allowed by
Java Permissions)
+1, but we'll have to investigate how to do this.
AFAIK in Jetspeed 2.1.3 was as restrictive in this respect or I
overlooked something big-time when I devised and implemented the new
solution.
It probably didn't work as expected in 2.1.3 either, not trying to say
the new implementation broke something here, just saying "it ain't
working so lets fix it" :)
JIRA issue:
https://issues.apache.org/jira/browse/JS2-1059
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
