directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject [jira] Updated: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Date Sun, 18 Apr 2004 05:42:29 GMT
The following issue has been updated:

    Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
       Date: Sat, 17 Apr 2004 10:41 PM
    Comment:
Updated information to remain current namely ...

o changed names of classes reference to the ones created
o corrected the actual object types pushed and popped off object stack

    Changes:
             description changed from BindRequest for Simple Binding
==============================

* The LOW level BER operation should not have to create objects for simple types that need
to be used with a stack.  These types can be pushed and poped off of primitive stacks which
we have added to the digester.

* We must recognize that there will be different kinds of rules. Some will be non protocol
specific or rather BER specific which will perhaps be used to transform primitive types. 
Other rules will be protocol specific and then there will be PDU specific rules.

Now for our specific problem of building a BindRequest lets keep the scope constrained to
simple binds without any controls.  Below we have the tag nesting patterns of such a bind
request:


.|..0x30 <-------- SEQUENCE
.|......0x02 <-------- INTEGER (messageId)
.|......0x40 <-------- BindRequest (APPLICATION 0)
.|..........0x02 <-------- INTEGER (version)
.|..........0x04 <-------- OCTET STRING (name)
.|..........0x80 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
 v
time

The BindRequest pattern would then be { 0x30, 0x40 } however before it comes the messageId
which we need to create the BindRequest bean.  

A protocol non specific rule can be devised to accumulate and decode the message id integer
by matching for { 0x30, 0x02 }.  It could be called PrimitiveIntDecodeRule.  Lets say that
it accumulates, decodes and pushes a primitive int onto the primitive int stack for use later
as a parameter.  To summerize this step:

addRule( { 0x30, 0x02 }, PrimitiveIntDecodeRule ) ;

A PDU specific rule, LdapBindRequestRule would then match the tag pattern, { 0x30, 0x40 },
pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.

addRule( { 0x30, 0x40 }, LdapBindRequestRule ) ;

Next we encounter the sequence of members we need for this PDU.  For the version INTEGER we
register two rules in the following order.

addRule( { 0x30, 0x40, 0x02 }, PrimitiveIntDecodeRule ) ;
addRule( { 0x30, 0x40, 0x02 }, LdapBindSetVersion ) ;

Continuing on we set the distinguished name of the user that is binding.  This also is best
handled in a two step process.  The first rule simply accumulates a byte array and pushes
it onto the object stack.  The next rule pops the byte array off of the object stack, generates
a UNICODE string, and parses it to generate a LdapName object which it then uses to set the
name property of the bind request.  The rules to handle this stage are as follows:

addRule( { 0x30, 0x40, 0x04 }, OctetStringRule ) ;
addRule( { 0x30, 0x40, 0x04 }, LdapBindSetName ) ;

Now for the last step we're reading an OCTET STRING that is tagged as a context specific [0]
tag for the simple credentials.  Again we use a dual rule combination:

addRule( { 0x30, 0x40, 0x80 }, OctetStringRule ) ;
addRule( { 0x30, 0x40, 0x80 }, LdapBindSetSimpleCredentials ) ;

Here the first rule simply collects the credential data into a byte array and pushes it onto
the object stack.  The second rule pops the byte[] off of the object stack and sets the BindRequest
bean's credentials which is the root object as well as the current top of the object stack.
 The second rule also sets the 'simple' boolean property to true.  

Finally the LdapBindRequestRule finishes at which point the completed BindRequest bean can
be popped off of the object stack and handed off to a higher facility.

Rules to be created:

<ol>
  <li>PrimitiveIntDecodeRule</li>
  <li>LdapBindRequestRule</li>
  <li>OctetStringRule</li>
  <li>LdapBindSetName</li>
  <li>LdapBindSetSimpleCredentials</li>
</ol>

 to BindRequest for Simple Binding
==============================

* The LOW level BER operation should not have to create objects for simple types that need
to be used with a stack.  These types can be pushed and poped off of primitive stacks which
we have added to the digester.

* We must recognize that there will be different kinds of rules. Some will be non protocol
specific or rather BER specific which will perhaps be used to transform primitive types. 
Other rules will be protocol specific and then there will be PDU specific rules.  We 
found that primitive rule types can be extended for customization.

Now for our specific problem of building a BindRequest lets keep the scope constrained to
simple binds without any controls.  Below we have the tag nesting patterns of such a bind
request:


.|..0x30 <-------- SEQUENCE
.|......0x02 <-------- INTEGER (messageId)
.|......0x40 <-------- BindRequest (APPLICATION 0)
.|..........0x02 <-------- INTEGER (version)
.|..........0x04 <-------- OCTET STRING (name)
.|..........0x80 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
 v
time

The BindRequest pattern would then be { 0x30, 0x40 } however before it comes the messageId
which we need to create the BindRequest bean.  

A protocol non specific rule can be devised to accumulate and decode the message id integer
by matching for { 0x30, 0x02 }.  It could be called PrimitiveIntDecodeRule.  Lets say that
it accumulates, decodes and pushes a primitive int onto the primitive int stack for use later
as a parameter.  To summerize this step:

addRule( { 0x30, 0x02 }, PrimitiveIntDecodeRule ) ;

A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x30, 0x40 }, pop
the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.

addRule( { 0x30, 0x40 }, BindRequestRule ) ;

Next we encounter the sequence of members we need for this PDU.  
For the version INTEGER we register the following rule which
extends the PrimitiveIntDecodeRule.

addRule( { 0x30, 0x40, 0x02 }, BindVersionRule ) ;

Continuing on we set the distinguished name of the user that is binding.  The BindNameRule
is derived from the PrimitiveOctetStringRule which pushes the collected octets for the name
field onto the object stack.  The finish() method override after calling the super method
pops the octets off of the stack and uses it for constructing the name field.  Here's the
add for the rule:

addRule( { 0x30, 0x40, 0x04 }, BindNameRule ) ;

Now for the last step we're reading an OCTET STRING that is tagged as a context specific [0]
tag for the simple credentials.  Again this rule extends the PrimitiveOctetStringRule and
encounters the same dynamics.  Here's how it is added:

addRule( { 0x30, 0x40, 0x80 }, BindSimpleCredentialsRule ) ;

Here the rule simply collects the credential data into a byte array and pushes it onto the
object stack.  The finish() method override pops the byte[] off of the object stack and sets
the BindRequest bean's credentials which is the root object as well as the current top of
the object stack.  The rule also sets the 'simple' boolean property to true.  

Finally the LdapBindRequestRule finishes at which point the completed BindRequest bean can
be popped off of the object stack and handed off to a higher facility.

Rules to be created and added:

<ol>
  <li>PrimitiveIntDecodeRule</li>
  <li>BindRequestRule</li>
  <li>BindVersionRule</li>
  <li>BindNameRule</li>
  <li>BindSimpleCredentialsRule</li>
</ol>


    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/DIRSNICKERS-7?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/DIRSNICKERS-7

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: DIRSNICKERS-7
    Summary: Work on BindRequest construction with BERDigester
       Type: Task

     Status: In Progress
   Priority: Major

    Project: Directory Snickers
 Components: 
             BER Runtime

   Assignee: Alex Karasulu
   Reporter: Alex Karasulu

    Created: Sun, 4 Apr 2004 10:13 PM
    Updated: Sat, 17 Apr 2004 10:41 PM

Description:
BindRequest for Simple Binding
==============================

* The LOW level BER operation should not have to create objects for simple types that need
to be used with a stack.  These types can be pushed and poped off of primitive stacks which
we have added to the digester.

* We must recognize that there will be different kinds of rules. Some will be non protocol
specific or rather BER specific which will perhaps be used to transform primitive types. 
Other rules will be protocol specific and then there will be PDU specific rules.  We 
found that primitive rule types can be extended for customization.

Now for our specific problem of building a BindRequest lets keep the scope constrained to
simple binds without any controls.  Below we have the tag nesting patterns of such a bind
request:


.|..0x30 <-------- SEQUENCE
.|......0x02 <-------- INTEGER (messageId)
.|......0x40 <-------- BindRequest (APPLICATION 0)
.|..........0x02 <-------- INTEGER (version)
.|..........0x04 <-------- OCTET STRING (name)
.|..........0x80 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
 v
time

The BindRequest pattern would then be { 0x30, 0x40 } however before it comes the messageId
which we need to create the BindRequest bean.  

A protocol non specific rule can be devised to accumulate and decode the message id integer
by matching for { 0x30, 0x02 }.  It could be called PrimitiveIntDecodeRule.  Lets say that
it accumulates, decodes and pushes a primitive int onto the primitive int stack for use later
as a parameter.  To summerize this step:

addRule( { 0x30, 0x02 }, PrimitiveIntDecodeRule ) ;

A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x30, 0x40 }, pop
the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.

addRule( { 0x30, 0x40 }, BindRequestRule ) ;

Next we encounter the sequence of members we need for this PDU.  
For the version INTEGER we register the following rule which
extends the PrimitiveIntDecodeRule.

addRule( { 0x30, 0x40, 0x02 }, BindVersionRule ) ;

Continuing on we set the distinguished name of the user that is binding.  The BindNameRule
is derived from the PrimitiveOctetStringRule which pushes the collected octets for the name
field onto the object stack.  The finish() method override after calling the super method
pops the octets off of the stack and uses it for constructing the name field.  Here's the
add for the rule:

addRule( { 0x30, 0x40, 0x04 }, BindNameRule ) ;

Now for the last step we're reading an OCTET STRING that is tagged as a context specific [0]
tag for the simple credentials.  Again this rule extends the PrimitiveOctetStringRule and
encounters the same dynamics.  Here's how it is added:

addRule( { 0x30, 0x40, 0x80 }, BindSimpleCredentialsRule ) ;

Here the rule simply collects the credential data into a byte array and pushes it onto the
object stack.  The finish() method override pops the byte[] off of the object stack and sets
the BindRequest bean's credentials which is the root object as well as the current top of
the object stack.  The rule also sets the 'simple' boolean property to true.  

Finally the LdapBindRequestRule finishes at which point the completed BindRequest bean can
be popped off of the object stack and handed off to a higher facility.

Rules to be created and added:

<ol>
  <li>PrimitiveIntDecodeRule</li>
  <li>BindRequestRule</li>
  <li>BindVersionRule</li>
  <li>BindNameRule</li>
  <li>BindSimpleCredentialsRule</li>
</ol>




---------------------------------------------------------------------
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


Mime
View raw message