[
https://issues.apache.org/jira/browse/DIRAPI-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRAPI-323.
--------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0.AM3
The way it's now handled is that we create an Opaque ExtOp that we convert to a
typed ExtOp once we have detected the ExtOp type.
It works, even if not efficient. A better solution would be to add a
post-grammar-end action to create the proper ExtOp only once.
> 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
> Priority: Minor
> Fix For: 2.0.0.AM3
>
>
> 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)
