directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: Problem with SchemaService
Date Fri, 11 Nov 2005 00:40:59 GMT
Turkalj, Claus wrote:

> I am just trying to upgrade from 0.9 to 0.9.3.
>
Well there are many bug fixes as well to benefit from along with the 
list of features.

> For version 0.9 I implemented my own Interceptor called ACIService 
> which does some basic access control checking and throws a 
> NoPermissionException if the caller is not authorized to add/delete or 
> modify an entry.
>
> I know there is an ACIItem implementation in 0.9.3 but since I 
> couldn't find any expample for ldif files I decided to continue to use 
> my working ACIService.
>
Ok.  Keep in mind that test cases are a great place to look when the 
documentation is anemic as is the case here today.  There is now some 
documentation on the site about the new authorization mechanism:


> In one test case I am removing a user from a group by removing the 
> attribute uniqueMember=<userDN> from the group entry. Since the caller 
> in this particular test case is not allowed to do this I throw a 
> NoPermissionException in the ACIService and check that this exception 
> occurs and that the attribute uniqueMember=<userDN> still exists in 
> the group entry.
>
> With 0.9.3 the test fails, the exception is thrown but the attribute 
> doesn't exist any more.
>
Not good a sign that the exception is being thrown after the commit to 
the database.

> After long debugging sessions I found out that the SchemaService which 
> is called before my ACIService interceptor in the interceptor chain 
> modified the attribute.
>
Hmm that should not happen (bug) ... basically the last interceptor in 
the chain is responsible for actually making the call against the nexus. 

...

>         // can't do math to figure our if all values are removed since 
> some
>         // values in the modify request may not be in the entry.  we 
> need to
>         // remove the values from a cloned version of the attribute 
> and see
>         // if nothing is left.
>         Attribute changedEntryAttr = (Attribute)entry.get( 
> change.getID() );
>        
>         for ( int jj = 0; jj < change.size(); jj++ )
>         {
>             changedEntryAttr.remove( change.get( jj ) );
>         }
>
>         return changedEntryAttr.size() == 0;
>     }
>
> When I changed
>
>         Attribute changedEntryAttr = (Attribute)entry.get( 
> change.getID() );
> to
>
>         Attribute changedEntryAttr = (Attribute)entry.get( 
> change.getID() ).clone;
>
> everything worked as expected.
>
Could you file this into JIRA with a high severity level.  Looks like I 
have forgotten to clone the entry.  I just need to check around in the 
context where this is occurring to make sure it's an ok change. 

Thanks,
Alex



Mime
View raw message