You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by ji...@apache.org on 2004/04/18 22:45:53 UTC
[jira] Updated: (DIRSNICKERS-40) Write BindResponse rules
The following issue has been updated:
Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
Date: Sun, 18 Apr 2004 1:43 PM
Changes:
description changed from Need to start writing the bind response rules. Here's the anatomy of the bind response in raw tags with the primitive bit turned off:
to 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)
v
time
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.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/DIRSNICKERS-40?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIRSNICKERS-40
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIRSNICKERS-40
Summary: Write BindResponse rules
Type: Task
Status: In Progress
Priority: Major
Project: Directory Snickers
Components:
LDAP Provider
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 18 Apr 2004 1:17 PM
Updated: Sun, 18 Apr 2004 1:43 PM
Description:
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)
v
time
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.
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira