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/05 07:14:43 UTC
[jira] Created: (DIR-89) Work on BindRequest construction with BERDigester
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIR-89
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIR-89
Summary: Work on BindRequest construction with BERDigester
Type: Task
Status: Open
Priority: Major
Project: Directory
Components:
Eve
ldap
Snickers
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 4 Apr 2004 10:13 PM
Description:
BindRequest for Simple Binding
==============================
SEQUENCE 0x30, 0xxx,
INTEGER 0x02 0x....
CHOICE bindRequest 0x40
SEQUENCE 0x30, 0xxx
INTEGER version 0x02
OCTET STRING name 0x04 0x...
CHOICE
OCTET STRING simple 0x04 0x...
BERDigester should have a general rule that tracks the current message
id. It can push an Integer instance of the MessageId onto the stack
when ever a pattern of tags { 0x30, 0x02 } are encountered. Before the
actual BindRequest pattern is hit this object would be popped off of the
stack but will be available through the "root" member referrence.
The BindRequest pattern would then be { 0x30, 0x40 }. With this and
the message id we could easily create an empty request and push it
onto the stack to be populated by other rules.
0x30
0x02
0x40
0x30
0x02
0x04
0x04
0x00
It might be a good idea to implement some of the simpler constructs
firsts with rules and reuse them when building higher message level
rule sets.
Here's what we can make for BindRequest now that can be reused:
BindRequestRule
LdapDnRule
IntegerRule
OctetStringRule
---------------------------------------------------------------------
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
[jira] Closed: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
Message:
The following issue has been closed.
Resolver: Alex Karasulu
Date: Sun, 18 Apr 2004 1:02 PM
Completed and checked in the last set of tests to show the bind request being built properly see commit rev 10086 for details.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
Project: Directory Snickers
Components:
BER Runtime
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 18 Apr 2004 1:02 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 raw tag nesting patterns of such a bind request with the primitive bit turned off:
.|..0x10000000 <-------- SEQUENCE
.|......0x02000000 <-------- INTEGER (messageId)
.|......0x40000000 <-------- BindRequest (APPLICATION 0)
.|..........0x02000000 <-------- INTEGER (version)
.|..........0x04000000 <-------- OCTET STRING (name)
.|..........0x80000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
v
time
The BindRequest pattern would then be { 0x10000000, 0x40000000 } 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 { 0x10000000, 0x02000000 }. 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( { 0x10000000, 0x02000000 }, PrimitiveIntDecodeRule ) ;
A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x10000000, 0x40000000 }, pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.
addRule( { 0x10000000, 0x40000000 }, 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( { 0x10000000, 0x40000000, 0x02000000 }, 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( { 0x10000000, 0x40000000, 0x04000000 }, 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( { 0x10000000, 0x40000000, 0x80000000 }, 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
[jira] Reopened: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
Message:
The following issue has been reopened.
Reopener: Alex Karasulu
Date: Sun, 18 Apr 2004 1:47 PM
We might need to reconsider the way we whipped this together. It might be better to use primitive operations to have several pushes on to the respective stack. Then the top level object can just do several pop operations on the respective stacks. Might have to double back on this a little bit to do it write. It works for now but we did not need to create all these rule classes. It was excessive now that I look back on it.
---------------------------------------------------------------------
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: Reopened
Priority: Major
Project: Directory Snickers
Components:
BER Runtime
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 18 Apr 2004 1:47 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 raw tag nesting patterns of such a bind request with the primitive bit turned off:
.|..0x10000000 <-------- SEQUENCE
.|......0x02000000 <-------- INTEGER (messageId)
.|......0x40000000 <-------- BindRequest (APPLICATION 0)
.|..........0x02000000 <-------- INTEGER (version)
.|..........0x04000000 <-------- OCTET STRING (name)
.|..........0x80000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
v
time
The BindRequest pattern would then be { 0x10000000, 0x40000000 } 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 { 0x10000000, 0x02000000 }. 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( { 0x10000000, 0x02000000 }, PrimitiveIntDecodeRule ) ;
A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x10000000, 0x40000000 }, pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.
addRule( { 0x10000000, 0x40000000 }, 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( { 0x10000000, 0x40000000, 0x02000000 }, 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( { 0x10000000, 0x40000000, 0x04000000 }, 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( { 0x10000000, 0x40000000, 0x80000000 }, 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
[jira] Updated: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
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
[jira] Updated: (DIR-89) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
Date: Sun, 11 Apr 2004 12:30 AM
Comment:
adding the rules that need to be created
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.
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.
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>
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/DIR-89?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIR-89
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIR-89
Summary: Work on BindRequest construction with BERDigester
Type: Task
Status: In Progress
Priority: Major
Project: Directory
Components:
Eve
ldap
Snickers
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 11 Apr 2004 12:30 AM
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.
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>
---------------------------------------------------------------------
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
[jira] Updated: (DIR-89) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
Date: Sun, 11 Apr 2004 12:16 AM
Comment:
o correctly represented the anatomy of the bind request
o added some suggestions which nicely distinguish between encoding specific rules, protocol specific rules and even more specific PDU rules
o prepared now to start building some rules
Changes:
description changed from BindRequest for Simple Binding
==============================
SEQUENCE 0x30, 0xxx,
INTEGER 0x02 0x....
CHOICE bindRequest 0x40
SEQUENCE 0x30, 0xxx
INTEGER version 0x02
OCTET STRING name 0x04 0x...
CHOICE
OCTET STRING simple 0x04 0x...
BERDigester should have a general rule that tracks the current message
id. It can push an Integer instance of the MessageId onto the stack
when ever a pattern of tags { 0x30, 0x02 } are encountered. Before the
actual BindRequest pattern is hit this object would be popped off of the
stack but will be available through the "root" member referrence.
The BindRequest pattern would then be { 0x30, 0x40 }. With this and
the message id we could easily create an empty request and push it
onto the stack to be populated by other rules.
0x30
0x02
0x40
0x30
0x02
0x04
0x04
0x00
It might be a good idea to implement some of the simpler constructs
firsts with rules and reuse them when building higher message level
rule sets.
Here's what we can make for BindRequest now that can be reused:
BindRequestRule
LdapDnRule
IntegerRule
OctetStringRule
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.
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.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/DIR-89?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIR-89
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIR-89
Summary: Work on BindRequest construction with BERDigester
Type: Task
Status: In Progress
Priority: Major
Project: Directory
Components:
Eve
ldap
Snickers
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 11 Apr 2004 12:16 AM
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.
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.
---------------------------------------------------------------------
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
[jira] Updated: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
Date: Sun, 18 Apr 2004 1:01 PM
Comment:
Correcting the tag nesting of the tagStack.
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. 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>
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 raw tag nesting patterns of such a bind request with the primitive bit turned off:
.|..0x10000000 <-------- SEQUENCE
.|......0x02000000 <-------- INTEGER (messageId)
.|......0x40000000 <-------- BindRequest (APPLICATION 0)
.|..........0x02000000 <-------- INTEGER (version)
.|..........0x04000000 <-------- OCTET STRING (name)
.|..........0x80000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
v
time
The BindRequest pattern would then be { 0x10000000, 0x40000000 } 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 { 0x10000000, 0x02000000 }. 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( { 0x10000000, 0x02000000 }, PrimitiveIntDecodeRule ) ;
A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x10000000, 0x40000000 }, pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.
addRule( { 0x10000000, 0x40000000 }, 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( { 0x10000000, 0x40000000, 0x02000000 }, 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( { 0x10000000, 0x40000000, 0x04000000 }, 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( { 0x10000000, 0x40000000, 0x80000000 }, 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: Sun, 18 Apr 2004 1:01 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 raw tag nesting patterns of such a bind request with the primitive bit turned off:
.|..0x10000000 <-------- SEQUENCE
.|......0x02000000 <-------- INTEGER (messageId)
.|......0x40000000 <-------- BindRequest (APPLICATION 0)
.|..........0x02000000 <-------- INTEGER (version)
.|..........0x04000000 <-------- OCTET STRING (name)
.|..........0x80000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
v
time
The BindRequest pattern would then be { 0x10000000, 0x40000000 } 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 { 0x10000000, 0x02000000 }. 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( { 0x10000000, 0x02000000 }, PrimitiveIntDecodeRule ) ;
A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x10000000, 0x40000000 }, pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.
addRule( { 0x10000000, 0x40000000 }, 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( { 0x10000000, 0x40000000, 0x02000000 }, 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( { 0x10000000, 0x40000000, 0x04000000 }, 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( { 0x10000000, 0x40000000, 0x80000000 }, 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
[jira] Closed: (DIRSNICKERS-7) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
Message:
The following issue has been closed.
Resolver: Alex Karasulu
Date: Tue, 25 May 2004 3:01 PM
Looks like its pretty much done.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
Project: Directory Snickers
Components:
BER Runtime
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Tue, 25 May 2004 3:01 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 raw tag nesting patterns of such a bind request with the primitive bit turned off:
.|..0x10000000 <-------- SEQUENCE
.|......0x02000000 <-------- INTEGER (messageId)
.|......0x40000000 <-------- BindRequest (APPLICATION 0)
.|..........0x02000000 <-------- INTEGER (version)
.|..........0x04000000 <-------- OCTET STRING (name)
.|..........0x80000000 <-------- OCTET STRING (CONTEXT-SPECIFIC 0) (simple)
.|......0x80000000 <------------ Control (CONTEXT-SPECIFIC 0) (OPTIONAL)
v
time
The BindRequest pattern would then be { 0x10000000, 0x40000000 } 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 { 0x10000000, 0x02000000 }. 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( { 0x10000000, 0x02000000 }, PrimitiveIntDecodeRule ) ;
A PDU specific rule, BindRequestRule would then match the tag pattern, { 0x10000000, 0x40000000 }, pop the primitive int stack, instantiate a BindRequest bean and push it onto the object stack.
addRule( { 0x10000000, 0x40000000 }, 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( { 0x10000000, 0x40000000, 0x02000000 }, 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( { 0x10000000, 0x40000000, 0x04000000 }, 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( { 0x10000000, 0x40000000, 0x80000000 }, 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
[jira] Updated: (DIR-89) Work on BindRequest construction with BERDigester
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Alex Karasulu (mailto:aok123@bellsouth.net)
Date: Sun, 11 Apr 2004 12:19 AM
Comment:
Fixing spacing so the nesting pattern can be easilly discerned using dots to fill in spaces that are eaten up by JIRA.
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.
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.
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.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/DIR-89?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/DIR-89
Here is an overview of the issue:
---------------------------------------------------------------------
Key: DIR-89
Summary: Work on BindRequest construction with BERDigester
Type: Task
Status: In Progress
Priority: Major
Project: Directory
Components:
Eve
ldap
Snickers
Assignee: Alex Karasulu
Reporter: Alex Karasulu
Created: Sun, 4 Apr 2004 10:13 PM
Updated: Sun, 11 Apr 2004 12:19 AM
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.
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.
---------------------------------------------------------------------
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