directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Closed: (DIRSNICKERS-40) Write BindResponse rules
Date Sat, 29 May 2004 02:19:01 GMT

   The following issue has been closed.

   Resolver: Alex Karasulu
       Date: Fri, 28 May 2004 7:18 PM

Was fixed before, but required a deploy of the snacc-provider used in tests.  It was the snacc-provider
that was actually incomplete without SASL credential support.
View the issue:

Here is an overview of the issue:
        Key: DIRSNICKERS-40
    Summary: Write BindResponse rules
       Type: Task

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Directory Snickers
             LDAP Provider

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Sun, 18 Apr 2004 1:17 PM
    Updated: Fri, 28 May 2004 7:18 PM

Need to start writing the bind response rules.  Here's the anatomy of the bind response in
raw tags with the primitive/constructed bit turned off:

-o- the ASN.1 -o-

 BindResponse ::= [APPLICATION 1] SEQUENCE {

             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

-o- pattern -o-

.|..0x10000000 <-------- SEQUENCE 
.|......0x02000000 <-------- INTEGER (messageId) 
.|......0x41000000 <-------- BindResponse (APPLICATION 1) 
.|..........0x0a000000 <-------- ENUMERATION (resultCode) 
.|..........0x04000000 <-------- OCTET STRING (matchedDN) 
.|..........0x04000000 <-------- OCTET STRING (errorMessage) 
.|..........0x83000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 3) Referral (OPTIONAL)

.|..............0x04000000 <---- OCTET STRING for LDAPURL
                ( can have several of these in the seq) ;

.|..........0x87000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 7) serverSaslCreds (OPTIONAL)

.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL) 

The response actually is more complex than the request.  We should create a generic ResultRule
for the LDAPResult.  Note that the tricky part about this is in the fact that there are two
octet strings where order matters: matchedDN and errorMessage.  This is best handled by pushing
all parameters in the order they occur onto their respective stacks.  Then have the ResultRule
pop the appropriate stacks.  I need to make a separate issue for the ResultRule. 

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message