Results 1 to 5 of 5

Thread: Hibernate Based ACLs

  1. #1
    Join Date
    Mar 2005
    Posts
    22

    Default Hibernate Based ACLs

    Hi,

    I am currently evaluating Acegi Security for integration into one of our projects. So far, the product looks very promising. The data access layer of this project is based on Hibernate (surprise surprise) and I am currently wrestling with the SimpleAclEntry class.The problem arises on addPermission() and deletePermission() method calls which are inherited from AbstractBasicAclEntry.

    From looking at the source I can see that when these methods are called they reference the validPermissions array in the AbstractBasicAclEntry class. This array is popluated in the full constructor for the AbstractBasicAclEntry class by executing the getValidPermissions() method from a subclass of AbstractBasicAclEntry (in this case SimpleAclEntry). However in the no-arg constructor of AbstractBasicAclEntry, this initialization doesn't occur, so when addPermissions() or deletePermissions() is called on a Hibernated hydrated ACL, a NullPointerException is generated.

    So, the flow is:

    1. Hibernate hydrates an ACL by calling newInstance() (and thus calling the no-arg constructor of my simple extension to SimpleAclEntry.
    2. My no-arg constructor calls super(), and executes the no-arg constructor of AbstractBasicAclEntry, which does nothing.
    3. I then try to call addPermission(int permission) and get an NPE as the validPermissions array hasn't been populated.

    This problem won't just affect Hibernate, but any scheme that constructs any subclass of AbstractBasicAclEntry by calling the default constructor and then a bunch of setters.

    I can see a couple of hacks around the problem, but I must be missing something because this seems too basic a fault to have escaped previous detection. So basically, can anybody please tell me what I am missing?

    Thanks in advance,
    Deakin.

  2. #2
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    2,768

    Default

    AFAIK, most people are using the default DAOs we ship with Acegi Security (which us eSpring JDBC Abstraction layer, not Hibernate). I can see your problem. Would writing a Hibernate UserType provide a solution? Or do you suggest something be changed in the baseline Acegi Security classes?

  3. #3
    Join Date
    Mar 2005
    Posts
    22

    Default

    Hi Ben,

    Maybe this is too simplistic, but I think reworking the constructor ofAbstractBasicAclEntry would do it:

    Code:
    public AbstractBasicAclEntry()  {
    
         validPermissions = getValidPermissions();
          Arrays.sort(validPermissions);
    }
    I haven't worked through this end-to-end, but can you see any reason why this wouldn't be appropriate?

    Cheers,
    Deakin.

  4. #4
    Join Date
    Aug 2004
    Location
    Sydney, Australia
    Posts
    2,768

    Default

    Committed to CVS.

  5. #5
    Join Date
    Mar 2005
    Location
    Prague, Czech Republic
    Posts
    34

    Default

    Could you please provide code of your Hibernate DAOs?

    Tkank you

Similar Threads

  1. Replies: 9
    Last Post: Apr 4th, 2007, 03:09 AM
  2. Hibernate based AuthenticationDao issues
    By rwallace in forum Security
    Replies: 12
    Last Post: Aug 10th, 2005, 02:00 PM
  3. Loosing my SecureContext
    By sklakken in forum Security
    Replies: 3
    Last Post: Jul 21st, 2005, 01:44 PM
  4. Replies: 5
    Last Post: Apr 12th, 2005, 05:23 PM
  5. Replies: 3
    Last Post: Nov 19th, 2004, 07:16 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •