[ http://issues.apache.org/jira/browse/DIREVE-339?page=comments#action_12365005 ]
Alex Karasulu commented on DIREVE-339: -------------------------------------- Here's a commented out test case (testBadBindDnMalformed) that should be corrected to get the right exception type. http://svn.apache.org/viewcvs.cgi/directory/trunks/apacheds/simple/unit/src/test/java/org/apache/ldap/server/BadDnTest.java?rev=374520&view=markup > Decoder does no give sufficient information about errors so the LDAP server > can respond with correct result code. > ----------------------------------------------------------------------------------------------------------------- > > Key: DIREVE-339 > URL: http://issues.apache.org/jira/browse/DIREVE-339 > Project: Directory Server > Type: Bug > Reporter: Alex Karasulu > Assignee: Alex Karasulu > > Right now a communication exception is thrown by the server when a malformed > DN is given in a PDU. I tested this with bind for example using a bad > BindDN. When the ASN1 codec fails the server cannot really tell the > difference between a bad protocol PDU which causes a protocolError (2) > resulting in a JNDI CommunicationException from a bad DN which should return > a resultCode of namingViolation (64) which in JNDI comes back to the client > as an InvalidNameException. For more info on resultCodes mapping to JNDI > exceptions see: > http://java.sun.com/products/jndi/jndi-ldap-gl.html#EXCEPT > Basically the ASN1 decoder has to throw exceptions with hints regarding the > failure to allow the server to respond appropriately to the client. This can > be done by embedding additional info such as a result code in an subclass of > DecoderException. Then the LdapProtocolProvider can access this info. > This problem is a direct result of trying to parse a DN for correctness when > this is not the responsibility of the ASN1 codec. The LDAP BER codec should > be giving stuff back to the server as is and letting the server determine > whether or not the dn or other (non-asn1 constrained) constructs are invalid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
