You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Thomas Gaebler (Jira)" <ji...@apache.org> on 2023/11/14 18:51:00 UTC

[jira] [Created] (DIRAPI-396) Additional loading of a schema not complete

Thomas Gaebler created DIRAPI-396:
-------------------------------------

             Summary: Additional loading of a schema not complete
                 Key: DIRAPI-396
                 URL: https://issues.apache.org/jira/browse/DIRAPI-396
             Project: Directory Client API
          Issue Type: Bug
    Affects Versions: 2.1.5
            Reporter: Thomas Gaebler


Hi community!

I have my own LDAP server implementation and use org.apache.directory.server libraries in version 2.0.0.AM27 and the API in version 2.1.5.

The LDAP server is called by various mail clients, including Thunderbird. If I start a simplified address book search in Thunderbird, I receive the following filter in the SearchRequest:
{code:java}
(|(|(cn=*test*)(givenName=*test*)(sn=*test*)(xmozillanickname=*test*)(mail=*test*)(mozillaSecondEmail=*test*)(description=*test*)(o=*test*)(ou=*test*)(title=*test*)(workurl=*test*)(homeurl=*test*))(objectClass=referral))) {code}
Not nice, but I have no influence on that.

The 'mozilla' schema is not loaded by default. So far I have loaded this at server startup using the following code:
{code:java}
schemaManager.loadDisabled( "mozilla" ); {code}
This has worked well so far. With the update to the latest versions, however, there is a problem. The received search query is now not parsed correctly. If I display it in the LOG, it now says:
{code:java}
(|(|(cn=*test*)(givenName=*test*)(sn=*test*)(Undefined:mozillaNickname)(mail=*test*)(Undefined:mozillaSecondEmail)(description=*test*)(o=*test*)(ou=*test*)(title=*test*)(Undefined:mozillaWorkUrl)(Undefined:mozillaHomeUrl))(objectClass=referral)) {code}
All mozilla attributes are now Undefined. The reason for this can be found here:
{code:java}
org.apache.directory.server.core.api.normalization.FilterNormalizingVisitor.visitSubstringNode(SubstringNode)
{

        AttributeType attributeType = schemaManager.lookupAttributeTypeRegistry( node.getAttribute() );
        MatchingRule substringMR = attributeType.getSubstring();
        
        if ( ( substringMR == null ) || ( substringMR.getNormalizer() == null ) )
        {
            // No normalizer for a Substring filter
            return new UndefinedNode( node.getAttribute() );
        }

        ...
}{code}
The MatchingRule (substringMR) for the mozilla Attributes is null. Only the substringOid is set. If fixed this for some attributes, but of course, it's a hack:
{code:java}
        schemaManager.loadDisabled( "mozilla" );
        
        Registries registries = schemaManager.getRegistries();
        MatchingRuleRegistry matchingRuleRegistry = registries.getMatchingRuleRegistry();
        List<String> attributeNames = asList( "mozillaSecondEmail", "mozillaNickname", "mozillaHomeUrl", "mozillaWorkUrl" );
        for ( var attributeName : attributeNames )
        {
            AttributeType attribute = schemaManager.lookupAttributeTypeRegistry( attributeName );
            
            attribute.unlock();
            if ( isNull( attribute.getSubstring() ) && nonNull( attribute.getSubstringOid() ) )
            {
                MatchingRule matchingRule = matchingRuleRegistry.lookup( attribute.getSubstringOid() );
                attribute.setSubstring( matchingRule );
            }
            
            if ( isNull( attribute.getEquality() ) && nonNull( attribute.getEqualityOid() ) )
            {
                MatchingRule matchingRule = matchingRuleRegistry.lookup( attribute.getEqualityOid() );
                attribute.setEquality( matchingRule );
            }
            
            if ( isNull( attribute.getOrdering() ) && nonNull( attribute.getOrderingOid() ) )
            {
                MatchingRule matchingRule = matchingRuleRegistry.lookup( attribute.getOrderingOid() );
                attribute.setOrdering( matchingRule );
            }
            attribute.lock();
        }
{code}
If I have overlooked something in the implementation so far, I would be grateful for a hint. But it looks like a bug.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org