class Net::LdapPdu

Constants

AddResponse
BindResult
DeleteResponse
ModifyRDNResponse
ModifyResponse
SearchResult
SearchResultReferral
SearchReturnedData

Attributes

app_tag[R]
msg_id[R]
search_attributes[R]
search_dn[R]
search_entry[R]
search_referrals[R]

Public Class Methods

new(ber_object) click to toggle source

initialize An LDAP PDU always looks like a BerSequence with at least two elements: an integer (message-id number), and an application-specific sequence. Some LDAPv3 packets also include an optional third element, which is a sequence of “controls” (See RFC 2251, section 4.1.12). The application-specific tag in the sequence tells us what kind of packet it is, and each kind has its own format, defined in RFC-1777. Observe that many clients (such as ldapsearch) do not necessarily enforce the expected application tags on received protocol packets. This implementation does interpret the RFC strictly in this regard, and it remains to be seen whether there are servers out there that will not work well with our approach.

Added a controls-processor to SearchResult. Didn’t add it everywhere because it just feels like it will need to be refactored.

# File lib/net/ldap/pdu.rb, line 74
def initialize ber_object
  begin
    @msg_id = ber_object[0].to_i
    @app_tag = ber_object[1].ber_identifier - 0x60
  rescue
    # any error becomes a data-format error
    raise LdapPduError.new( "ldap-pdu format error" )
  end

  case @app_tag
  when BindResult
    parse_ldap_result ber_object[1]
  when SearchReturnedData
    parse_search_return ber_object[1]
  when SearchResultReferral
    parse_search_referral ber_object[1]
  when SearchResult
    parse_ldap_result ber_object[1]
    parse_controls(ber_object[2]) if ber_object[2]
  when ModifyResponse
    parse_ldap_result ber_object[1]
  when AddResponse
    parse_ldap_result ber_object[1]
  when DeleteResponse
    parse_ldap_result ber_object[1]
  when ModifyRDNResponse
    parse_ldap_result ber_object[1]
  else
    raise LdapPduError.new( "unknown pdu-type: #{@app_tag}" )
  end
end

Public Instance Methods

parse_search_referral(uris) click to toggle source

A search referral is a sequence of one or more LDAP URIs. Any number of search-referral replies can be returned by the server, interspersed with normal replies in any order. Until I can think of a better way to do this, we’ll return the referrals as an array. It’ll be up to higher-level handlers to expose something reasonable to the client.

# File lib/net/ldap/pdu.rb, line 175
def parse_search_referral uris
  @search_referrals = uris
end
parse_search_return(sequence) click to toggle source

parse_search_return Definition from RFC 1777 (we’re handling application-4 here)

Search Response ::=

CHOICE {
     entry          [APPLICATION 4] SEQUENCE {
                         objectName     LDAPDN,
                         attributes     SEQUENCE OF SEQUENCE {
                                             AttributeType,
                                             SET OF AttributeValue
                                        }
                    },
     resultCode     [APPLICATION 5] LDAPResult
 }

We concoct a search response that is a hash of the returned attribute values. NOW OBSERVE CAREFULLY: WE ARE DOWNCASING THE RETURNED ATTRIBUTE NAMES. This is to make them more predictable for user programs, but it may not be a good idea. Maybe this should be configurable. ALTERNATE IMPLEMENTATION: In addition to @search_dn and @search_attributes, we also return @search_entry, which is an LDAP::Entry object. If that works out well, then we’ll remove the first two.

Provisionally removed obsolete search_attributes and search_dn, 04May06.

# File lib/net/ldap/pdu.rb, line 158
def parse_search_return sequence
  sequence.length >= 2 or raise LdapPduError
  @search_entry = LDAP::Entry.new( sequence[0] )
  #@search_dn = sequence[0]
  #@search_attributes = {}
  sequence[1].each {|seq|
    @search_entry[seq[0]] = seq[1]
    #@search_attributes[seq[0].downcase.intern] = seq[1]
  }
end
result_code(code = :resultCode) click to toggle source

result_code This returns an LDAP result code taken from the PDU, but it will be nil if there wasn’t a result code. That can easily happen depending on the type of packet.

# File lib/net/ldap/pdu.rb, line 112
def result_code code = :resultCode
  @ldap_result and @ldap_result[code]
end
result_controls() click to toggle source

Return RFC-2251 Controls if any. Messy. Does this functionality belong somewhere else?

# File lib/net/ldap/pdu.rb, line 118
def result_controls
  @ldap_controls || []
end

Private Instance Methods

parse_controls(sequence) click to toggle source

Per RFC 2251, an LDAP “control” is a sequence of tuples, each consisting of an OID, a boolean criticality flag defaulting FALSE, and an OPTIONAL Octet String. If only two fields are given, the second one may be either criticality or data, since criticality has a default value. Someday we may want to come back here and add support for some of more-widely used controls. RFC-2696 is a good example.

# File lib/net/ldap/pdu.rb, line 187
def parse_controls sequence
  @ldap_controls = sequence.map do |control|
    o = OpenStruct.new
    o.oid,o.criticality,o.value = control[0],control[1],control[2]
    if o.criticality and o.criticality.is_a?(String)
      o.value = o.criticality
      o.criticality = false
    end
    o
  end
end
parse_ldap_result(sequence) click to toggle source

parse_ldap_result

# File lib/net/ldap/pdu.rb, line 126
def parse_ldap_result sequence
  sequence.length >= 3 or raise LdapPduError
  @ldap_result = {:resultCode => sequence[0], :matchedDN => sequence[1], :errorMessage => sequence[2]}
end