Class Net::LdapPdu
In: lib/net/ldap/pdu.rb
Parent: Object

Methods

Constants

BindRequest = 0
BindResult = 1
UnbindRequest = 2
SearchRequest = 3
SearchReturnedData = 4
SearchResult = 5
ModifyResponse = 7
AddResponse = 9
DeleteResponse = 11
ModifyRDNResponse = 13
SearchResultReferral = 19
ExtendedRequest = 23
ExtendedResponse = 24

Attributes

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

Public Class methods

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.

Public Instance methods

(provisional, must document)

(provisional, must document)

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.

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.

(provisional, must document) UnbindRequest has no content so this is a no-op.

Returns a hash which (usually) defines the members :resultCode, :errorMessage, and :matchedDN. These values come directly from an LDAP response packet returned by the remote peer. See result_code for a sugaring.

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.

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

Return serverSaslCreds, which are only present in BindResponse packets. Messy. Does this functionality belong somewhere else? We ought to refactor the accessors of this class before they get any kludgier.

[Validate]