From: Graham B. <gb...@po...> - 2001-05-12 07:27:02
|
----- Forwarded message from Scott Bruce <sc...@te...> ----- Date: Fri, 11 May 2001 22:14:27 -0700 To: gb...@po... From: Scott Bruce <sc...@te...> Subject: Net::LDAP patch X-Mailer: Microsoft Outlook Express 6.00.2465.0000 Hi Graham, attached is the diff output from a quick patch I had to hack into Net::LDAP to get the schema stuff working with openldap 2.0.7 :-). by default openldap only returns attribute data for 'objectclass' and 'cn' if you request the subschema object, weird, so appending the other attribute names is neccessary if you want to do anything with the subschema object (like use it with Net::LDAP::Schema..). I found a small problem with Net::LDAP::Schema too; if an objectclass is missing MUST or MAY tokens (?) in the schema then Net::LDAP::Schema will barf when trying to construct a list of attributes for that objectclass.... thanks for the great module. -Scott *** Net/LDAP.pm Fri May 11 20:57:31 2001 --- /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP.pm Thu Sep 14 11:53:39 2000 *************** *** 664,681 **** } $mesg = $self->search( base => $base, scope => 'base', - ## 2001-05-11 ; openldap 2.0.x only returns cn && objectclass by default, - ## so explicitly request other attributes plus the defaults - attrs => [ - 'dITStructureRules', 'nameForms', 'ditContentRules', - 'attributeTypes', 'objectClasses', 'matchingRules', - 'matchingRuleUse', '*' - ], - ## filter => '(objectClass=*)', ); $mesg->code ? undef --- 664,673 ---- *** Net/LDAP/Schema.pm Fri May 11 20:31:05 2001 --- /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP/Schema.pm Wed Sep 13 08:08:05 2000 *************** *** 28,38 **** unless ($arg) { $schema->{error} = "Bad argument"; return undef; } ! %$schema = (); my $entry; if( ref $arg ) { if (UNIVERSAL::isa($arg, 'Net::LDAP::Entry')) { --- 28,38 ---- unless ($arg) { $schema->{error} = "Bad argument"; return undef; } ! %$schema = (); my $entry; if( ref $arg ) { if (UNIVERSAL::isa($arg, 'Net::LDAP::Entry')) { *************** *** 202,214 **** my %res; # Use hash to get uniqueness foreach my $oc ( @oc ) { my $oid = $self->is_objectclass( $oc ); if( $oid ) { ! ## 2001-05-11 patch to avoid errors if MUST or MAY are undefined :-) ! my $res = $self->{oid}->{$oid}->{$must_or_may} || []; ! ## my $res = $self->{oid}->{$oid}->{$must_or_may}; @res{ @$res } = (); # Add in, getting uniqueness } } return wantarray ? (keys %res) : [ keys %res ]; --- 202,212 ---- my %res; # Use hash to get uniqueness foreach my $oc ( @oc ) { my $oid = $self->is_objectclass( $oc ); if( $oid ) { ! my $res = $self->{oid}->{$oid}->{$must_or_may}; @res{ @$res } = (); # Add in, getting uniqueness } } return wantarray ? (keys %res) : [ keys %res ]; ----- End forwarded message ----- |
From: Chris R. <chr...@me...> - 2001-05-15 08:57:16
|
Graham Barr <gb...@po...> wrote: > ----- Forwarded message from Scott Bruce <sc...@te...> ----- > > Date: Fri, 11 May 2001 22:14:27 -0700 > To: gb...@po... > From: Scott Bruce <sc...@te...> > Subject: Net::LDAP patch > X-Mailer: Microsoft Outlook Express 6.00.2465.0000 > > Hi Graham, > > attached is the diff output from a quick patch I had to hack into > Net::LDAP to get the schema stuff working with openldap 2.0.7 :-). by > default openldap only returns attribute data for 'objectclass' and 'cn' > if you request the subschema object, weird, so appending the other No, that's sort of OK. The root DSE is handled a bit vaguely in the LDAP RFCs - to access it you should really use a manageDsaIT Control (which is not defined by any RFCs) because it is not a normal entry in the DIT. In the absence of this standard control servers are either 'helpful' and return all the (operational) attributes - pretending the control's been set, effectively - or 'strict' and don't. For normal entries, servers are not supposed to return any operational attributes that have not explicitly been requested. Clearly this is what the OpenLDAP server is doing with the root. > attribute names is neccessary if you want to do anything with the > subschema object (like use it with Net::LDAP::Schema..). That change was included as part of the rejig of the schema code in 0.23, except that we also retrieve the ldapSyntaxes attribute as well. > I found a small problem with Net::LDAP::Schema too; if an objectclass is > missing MUST or MAY tokens (?) in the schema then Net::LDAP::Schema will > barf when trying to construct a list of attributes for that > objectclass.... There looks to be some code in the current Net::LDAP::Schema.pm file that deals with this situation too. Try getting the latest version of Net::LDAP! Cheers, Chris |
From: Chris R. <chr...@me...> - 2001-05-15 09:47:28
|
Chris Ridd <chr...@me...> wrote: > Graham Barr <gb...@po...> wrote: >> ----- Forwarded message from Scott Bruce <sc...@te...> ----- >> >> Date: Fri, 11 May 2001 22:14:27 -0700 >> To: gb...@po... >> From: Scott Bruce <sc...@te...> >> Subject: Net::LDAP patch >> X-Mailer: Microsoft Outlook Express 6.00.2465.0000 >> >> Hi Graham, >> >> attached is the diff output from a quick patch I had to hack into >> Net::LDAP to get the schema stuff working with openldap 2.0.7 :-). by >> default openldap only returns attribute data for 'objectclass' and 'cn' >> if you request the subschema object, weird, so appending the other > > No, that's sort of OK. The root DSE is handled a bit vaguely in the LDAP > RFCs - to access it you should really use a manageDsaIT Control (which is > not defined by any RFCs) because it is not a normal entry in the DIT. In > the absence of this standard control servers are either 'helpful' and > return all the (operational) attributes - pretending the control's been > set, effectively - or 'strict' and don't. I should add that there is a non-standard manageDsaIT control. It is described in section 8 of draft-zeilenga-ldap-namedref-00.txt, of which this is an excerpt: ==== The control type is 2.16.840.1.113730.3.4.2. The control criticality may be TRUE or FALSE. There is no value; the controlValue field is absent. ==== Cheers, Chris |