Nathan Sarr wrote:
> Hello,
>
> Here are a few patches that I hope will help. I also have a few questions
> and was wondering if anyone would mind offering some advice / help.
>
> For the patches -
>
> BasePermissions.java.patch.txt - I added DELETE to the BasePermissions class.
> PermissionsTest.java.patch.txt - I updated the test to pass
> AclImpl.java.patch.txt - changed the code to look for an offset of -1 to
> throw NotFoundException
Thanks Nate. I've applied them to SVN.
>
> For the Questions.
>
> 1. I was wondering how does an Access Control Entry get an id? Can it
> only get an id through persistence? I noticed
> in the AclImpl, when I create an ACE, there is no way to specify the ace id
> in the method:
>
> public void insertAce(Long afterAceId, Permission permission, Sid sid,
> boolean granting)
The persistence layer is expected to inject them. The constructor of
AccessControlEntryImpl accepts an id argument, although it is optional.
There is no mutator provided for the id field, so field level access
should be used to achieve it. Code like this will do it (if you're not
using Hibernate, JPA or something else which can natively deal with
field level access):
public static void setProtectedField(String protectedField, Object
object, Object newValue) {
setProtectedField(object.getClass(), protectedField, object,
newValue);
}
private static void setProtectedField(Class clazz, String
protectedField, Object object, Object newValue) {
Field field = null;
try {
field = clazz.getDeclaredField(protectedField);
} catch (final NoSuchFieldException nsf) {
logger.warn(nsf);
}
if (field == null) {
// Unable to locate, so try the superclass (if there is
one)
if (clazz.getSuperclass() != null) {
setProtectedField(clazz.getSuperclass(),
protectedField, object,
newValue);
} else {
throw new IllegalArgumentException("Couldn't
find '" +
protectedField + "' field");
}
} else {
// We have a field, so process
field.setAccessible(true);
try {
field.set(object, newValue);
} catch (final Exception ex) {
throw new IllegalStateException(ex);
}
}
}
> 2. I was also wondering if anyone has considered a persistence strategy for
> Permissions. For example I was testing adding a Cumulative Permission to an
> Access Control Entry vs storing a Base Permission. Would it be recommend the
> different permission class types be stored in the database along with the
> permission and loading them based on this?
The persistence layer works with AccessControlEntry instances, which in
turn hold an implementation of the Permission interface. In turn,
Permission can be constructed from either the BasePermission class or
the CumulativePermission class. It is expected that people will use
CumulativePermission to construct Permission implementations that are
suitable for persistence. BasePermission should remain used solely for
"top level" permissions which represent a single bit.
CumulativePermission should be used whenever it is necessary to have
more than one bit high in a mask.
Cheers
Ben
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
