You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Alex Karasulu (JIRA)" <di...@incubator.apache.org> on 2006/02/02 22:46:05 UTC
[jira] Created: (DIREVE-339) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
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
Assigned to: 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
[jira] Assigned: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=all ]
Alex Karasulu reassigned DIRSERVER-309:
---------------------------------------
Assignee: Emmanuel Lecharny (was: Alex Karasulu)
Emmanuel is currently working on this issue.
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assigned To: Emmanuel Lecharny
>
> 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
[jira] Updated: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=all ]
Alex Karasulu updated DIRSERVER-309:
------------------------------------
Component: ldap
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assignee: Emmanuel Lecharny
>
> 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
[jira] Commented: (DIREVE-339) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <di...@incubator.apache.org>.
[ 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
[jira] Assigned: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=all ]
Alex Karasulu reassigned DIRSERVER-309:
---------------------------------------
Assignee: Alex Karasulu (was: Emmanuel Lecharny)
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assigned To: 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
[jira] Commented: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=comments#action_12428794 ]
Alex Karasulu commented on DIRSERVER-309:
-----------------------------------------
I think the best way to approach this problem is as we discussed. Let's make a special message type handler and register it for Exceptions. Instead of propagating exceptions by throwing them we can bubble up the message to this handler which can properly respond to the client.
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assigned To: Emmanuel Lecharny
>
> 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
[jira] Closed: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Alex Karasulu (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=all ]
Alex Karasulu closed DIRSERVER-309.
-----------------------------------
fixed and confirmed
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assigned To: Emmanuel Lecharny
>
> 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
[jira] Resolved: (DIRSERVER-309) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Emmanuel Lecharny (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DIRSERVER-309?page=all ]
Emmanuel Lecharny resolved DIRSERVER-309.
-----------------------------------------
Resolution: Duplicate
This is DIRSERVER-711. No need to have two JIRAs for the same issue !
> Decoder does no give sufficient information about errors so the LDAP server can respond with correct result code.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-309
> URL: http://issues.apache.org/jira/browse/DIRSERVER-309
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Reporter: Alex Karasulu
> Assigned To: Emmanuel Lecharny
>
> 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
[jira] Commented: (DIREVE-339) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-339?page=comments#action_12365014 ]
Emmanuel Lecharny commented on DIREVE-339:
------------------------------------------
This is a real problem, but we can fix it fast.
What are our options here ?
1) Just don't take the responsability of detecting bad DN in ASN.1 codec. Then we will send the created DN to the next layer
2) Assume that we test that the DN syntax is valid, but we must throw an error allowing the client to be informed of the cause of the error.
I personnaly assumed that the second solution was better, in a sense that I build a LdapDN (it should be renamed LdapName), which internally contains RDN. So an invalid DN will lead top incorrect inner structure. That was a choice, of course. The alternative was to store the String, instead of building a valid DN.
However, in this case, the thrown exception is not good. May be wa can throw a specific exception for that purpose, but that mean a special handling in the protocol layer. I'm not totally happy with that solution. An other way to go is to set a flag to tell the MessageHandler that the DN was incorrect. Or simply forget about the control, and just store the value as it, without parsing it. We just have to add a method to store this UP name into a ldapDN.
wdyt is best ?
> 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
[jira] Assigned: (DIREVE-339) Decoder does no give sufficient
information about errors so the LDAP server can respond with correct result
code.
Posted by "Emmanuel Lecharny (JIRA)" <di...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/DIREVE-339?page=all ]
Emmanuel Lecharny reassigned DIREVE-339:
----------------------------------------
Assign To: Emmanuel Lecharny (was: Alex Karasulu)
> 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: Emmanuel Lecharny
>
> 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