Emmanuel Lecharny created DIRAPI-323:
----------------------------------------
Summary: Decoding extended operations which require a value isn't
enforcing the value to be present
Key: DIRAPI-323
URL: https://issues.apache.org/jira/browse/DIRAPI-323
Project: Directory Client API
Issue Type: Bug
Affects Versions: 2.0.0.AM2
Reporter: Emmanuel Lecharny
Currently, when we decode an extended operation for which we know about (ie,
it's registred in the {{LdapApiService}} instance), and if the {{RequestValue}}
part is required, we have no way to enforce it to be present, which means the
decoding will succeed, even if the resulting extended operation is invalid.
This is due to the fact that the extended operation grammar makes the value
optionnal :
{noformat}
ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
requestName [0] LDAPOID,
requestValue [1] OCTET STRING OPTIONAL }
ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
COMPONENTS OF LDAPResult,
responseName [10] LDAPOID OPTIONAL,
responseValue [11] OCTET STRING OPTIONAL }
{noformat}
(works for a request or a response), while for a specific implementation, like
the {{CancelRequest}}, defined in [RFC
3909|https://www.rfc-editor.org/rfc/rfc3909.txt], the grammar is :
{noformat}
The Cancel request is an ExtendedRequest with the requestName field
containing 1.3.6.1.1.8 and a requestValue field which contains a
BER-encoded cancelRequestValue value.
cancelRequestValue ::= SEQUENCE {
cancelID MessageID
-- MessageID is as defined in [RFC2251]
}
{noformat}
and it's clearly not optional.
It boils down to be able to detect the extended operation type (given by the
request name, if present), and then check if the request value is present or
not. It's a semantic check, while the decoding just take care of the syntax,
which makes it impossible to detect such a missing value.
There is a solution for PDU which ends with no controls, as we can tell the
grammar that there is some expected value, which will fail if the PDU ends, but
if we have controls, then the grammar will keep going as some more data is
present (we just have to change the {{isGrammarEndAllowed}} to {{false}} to
make that works when no control is present, but obviously that does not work
when we have some controls).
ATM, I have no solution to this problem. What would be required is to set a
flag when we meet the {{ExtendedOperation}} tag (ie {{0x77}} or {{0x78}}) and
check this flag when we have fully decoded a PDU, but this flag has a semantic
meaning, which would break the decoder as a generic ASN.1 decoder. One solution
would be to have the container check itself when we reach the {{PDU_DECODED}}
state in the {{Asn1Decoder}} loop...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
