Class: Net::LdapPdu

Inherits:
Object
  • Object
show all
Defined in:
lib/net/ldap/pdu.rb

Constant Summary collapse

BindResult =
1
SearchReturnedData =
4
SearchResult =
5
ModifyResponse =
7
AddResponse =
9
DeleteResponse =
11
ModifyRDNResponse =
13
SearchResultReferral =
19

Instance Attribute Summary collapse

Instance Method Summary collapse

Constructor Details

#initialize(ber_object) ⇒ LdapPdu

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.



74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
# 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

Instance Attribute Details

#app_tagObject (readonly)

Returns the value of attribute app_tag.



48
49
50
# File 'lib/net/ldap/pdu.rb', line 48

def app_tag
  @app_tag
end

#msg_idObject (readonly)

Returns the value of attribute msg_id.



48
49
50
# File 'lib/net/ldap/pdu.rb', line 48

def msg_id
  @msg_id
end

#search_attributesObject (readonly)

Returns the value of attribute search_attributes.



49
50
51
# File 'lib/net/ldap/pdu.rb', line 49

def search_attributes
  @search_attributes
end

#search_dnObject (readonly)

Returns the value of attribute search_dn.



49
50
51
# File 'lib/net/ldap/pdu.rb', line 49

def search_dn
  @search_dn
end

#search_entryObject (readonly)

Returns the value of attribute search_entry.



49
50
51
# File 'lib/net/ldap/pdu.rb', line 49

def search_entry
  @search_entry
end

#search_referralsObject (readonly)

Returns the value of attribute search_referrals.



50
51
52
# File 'lib/net/ldap/pdu.rb', line 50

def search_referrals
  @search_referrals
end

Instance Method Details

#parse_search_referral(uris) ⇒ Object

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.



175
176
177
# File 'lib/net/ldap/pdu.rb', line 175

def parse_search_referral uris
  @search_referrals = uris
end

#parse_search_return(sequence) ⇒ Object

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.



158
159
160
161
162
163
164
165
166
167
# 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) ⇒ Object

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.



112
113
114
# File 'lib/net/ldap/pdu.rb', line 112

def result_code code = :resultCode
  @ldap_result and @ldap_result[code]
end

#result_controlsObject

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



118
119
120
# File 'lib/net/ldap/pdu.rb', line 118

def result_controls
  @ldap_controls || []
end