Menu
▾
▴
perl-ldap-dev
|
From: Peter M. <pet...@ma...> - 2002-01-06 22:50:43
|
Hi,
I have two questions about the frmat of schema entries that
may be a little off topic, but bay also affect perl-ldap:
* Is ' (single quote) legal inside qdstrings in schema definitions=20
RFC2252 does not explicitely deny it. It simply gives the
following definitions
dstring =3D 1*utf8
qdstring =3D whsp "'" dstring "'" whsp
without defining utf8 further
Since a single quote is a utf8 character, this could mean
that single quotes inside qdstrings are really allowed.
So
DESC 'New Object's FS Rights'
might be a legal description.
* Is _ (underscore) a legal character in private extensions to
schema elements ?
RFC2252 does not explicitely forbid it.
It simply says:
"Terms which begin with the characters "X-" are reserved
for private experiments, and MUST be followed by a
<qdstrings>"
But no correlation is made between the word term and
any formally defined word.
So
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1'
might be a legal extension.
I do not ask this just for fun.
I find the assumptions made by Net::LDAP::Schema reasonable
(since the things above make parsing the schema quite hard).
But I have a directory server (guess which manufacturer ;-))
that contains those elements in the schema, making the schema
un-parseable by Net::LDAP::Schema.
Before I go out and tell them to correct their schema description
accordng to RFC I would like to get ohers' opinions if such a schema
conforms to RFC2252.
Last but not least, I have a very rough patch available that would allow
to parse such a schema. But I have to polish it a bitbefore I send it.
Are you interested ?
Yours
Peter
--=20
Peter Marschall | eMail: pet...@ma...
Scheffelstra=DFe 15 | pet...@is...
97072 W=FCrzburg | Tel: 0931/14721
PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
|
|
From: Graham B. <gb...@po...> - 2002-01-08 16:21:31
|
On Sun, Jan 06, 2002 at 09:00:28PM +0100, Peter Marschall wrote: > Hi, > > I have two questions about the frmat of schema entries that > may be a little off topic, but bay also affect perl-ldap: > > * Is ' (single quote) legal inside qdstrings in schema definitions > RFC2252 does not explicitely deny it. It simply gives the > following definitions > > dstring = 1*utf8 > qdstring = whsp "'" dstring "'" whsp > > without defining utf8 further > Since a single quote is a utf8 character, this could mean > that single quotes inside qdstrings are really allowed. > So > DESC 'New Object's FS Rights' > might be a legal description. An interesting question. It would make parsing rather interesting. You are right that the RFC does not disallow this. Net::LDAP assumed that no sensible person would do that (like many apps assume no sensible person puts spacing in filenames :) If you can provide a schema (or subset of one) with this I will see what I can do. > * Is _ (underscore) a legal character in private extensions to > schema elements ? > RFC2252 does not explicitely forbid it. > It simply says: > "Terms which begin with the characters "X-" are reserved > for private experiments, and MUST be followed by a > <qdstrings>" > But no correlation is made between the word term and > any formally defined word. > So > X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' > might be a legal extension. Yes, I think that is OK. Again an example will be most useful. > I do not ask this just for fun. > I find the assumptions made by Net::LDAP::Schema reasonable > (since the things above make parsing the schema quite hard). Right. Its not so much that it is hard, but it will be slower. > But I have a directory server (guess which manufacturer ;-)) I don't need to :) > that contains those elements in the schema, making the schema > un-parseable by Net::LDAP::Schema. > > Before I go out and tell them to correct their schema description > accordng to RFC I would like to get ohers' opinions if such a schema > conforms to RFC2252. > > Last but not least, I have a very rough patch available that would allow > to parse such a schema. But I have to polish it a bitbefore I send it. > Are you interested ? Sure. Don't spend too much time polishing it before letting others test it. Just a correct patch is fine, it can be polished later. Graham. |
|
From: Peter M. <pet...@ma...> - 2002-01-10 04:40:53
|
Hi,
On Tuesday 08 January 2002 17:21, you wrote:
> An interesting question. It would make parsing rather interesting. You =
are
> right that the RFC does not disallow this. Net::LDAP assumed that no
> sensible person would do that (like many apps assume no sensible person
> puts spacing in filenames :)
Who says they are sensible (maybe they just forgot quoting/escaping ;-))
> If you can provide a schema (or subset of one) with this I will see wha=
t I
> can do.
Of course, here it is for the single quotes and the undescores
(line breaking manually done by me):
attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
X-NDS_NAME 'New Object's DS Rights'
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
X-NDS_NAME 'New Object's FS Rights'
X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VAL=
UE
X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> > Last but not least, I have a very rough patch available that would al=
low
> > to parse such a schema. But I have to polish it a bitbefore I send i=
t.
> > Are you interested ?
> Sure. Don't spend too much time polishing it before letting others test=
it.
> Just a correct patch is fine, it can be polished later.
I warned you, it is very rough ;-)
More a very dirty kludge than a patch.
Its a unified diff againts perl-ldap 0.25 and atleast the
part in LDAP.pm violates the RFC that defined the
"vendorName" attribute in the roodDSE.
The RFC vedorName must not be used to change the
behaviour of applications. A better solution might be to
defined a global ldap option "alternate_schema_parser".
(the better parts of the code are shamelessly stolen from=20
other parts of perl-ldap ;-)
--- lib/Net/LDAP.pm
+++ lib/Net/LDAP.pm Wed Dec 26 20:46:03 2001
@@ -706,15 +706,18 @@
my %arg =3D @_;
my $base;
my $mesg;
+ my $vendor =3D 'unknown';
if (exists $arg{'dn'}) {
$base =3D $arg{'dn'};
}
else {
- my $root =3D $self->root_dse( attrs =3D> ['subschemaSubentry'] )
+ my $root =3D $self->root_dse( attrs =3D> ['subschemaSubentry', 'vend=
orName'=20
] )
or return undef;
$base =3D $root->get_value('subschemaSubentry') || 'cn=3Dschema';
+ # PM: look for attribute vendorName in rootDSE
+ $vendor =3D $root->get_value('vendorName') || 'unknown';
}
$mesg =3D $self->search(
@@ -733,9 +736,13 @@
)],
);
+ # PM: set Net::LDAP::schema option novellkludge if it is a Novell dire=
ctory
$mesg->code
? undef
- : Net::LDAP::Schema->new($mesg->entry);
+ : (($vendor =3D~ /Novell/i) ?
+ Net::LDAP::Schema->new($mesg->entry, novellkludge=3D>1) :
+ Net::LDAP::Schema->new($mesg->entry)
+ );
}
sub root_dse {
--- lib/Net/LDAP/Schema.pm
+++ lib/Net/LDAP/Schema.pm Wed Dec 26 20:59:24 2001
@@ -5,21 +5,71 @@
package Net::LDAP::Schema;
use strict;
-use vars qw($VERSION);
+use vars qw($VERSION %schemaParams);
$VERSION =3D "0.10";
+# PM: default schema parameters
+%schemaParams =3D ( novellkludge =3D> 0 );
+
+#
+# PM: get options from argument list (stolen from Net::LDAP & simplified=
)
+#
+sub _options {
+ my %ret =3D @_;
+ my $once =3D 0;
+ for my $v (grep { /^-/ } keys %ret) {
+ require Carp;
+ $once++ or Carp::carp("deprecated use of leading - for options");
+ $ret{substr($v,1)} =3D $ret{$v};
+ }
+
+ \%ret;
+}
+
+#
+# PM: get / set schema options
+#
+sub options
+{
+my $schema =3D shift if (@_ && ref($_[0]));
+my $params =3D &_options;
+
+ if ($params)
+ {
+ while (my ($key,$value) =3D each(%$params))
+ {
+ $schema->{params}->{$key} =3D $value if ($schema);
+ $schemaParams{$key} =3D $value;
+ }
+ }
+
+ return $schema ? %{$schema->{params}} : %schemaParams;
+}
+
+
#
# Get schema from the server (or read from LDIF) and parse it into
# data structure
+# PM: extended to accept hash of options after optional argument
#
sub new {
my $self =3D shift;
my $type =3D ref($self) || $self;
my $schema =3D bless {}, $type;
+ my $arg =3D shift if (@_ % 2);
+ my $opts =3D &_options;
+
+ # PM: set default options and optionally override them with given ones
+ $schema->{params} =3D { %schemaParams };
+ while (my ($key,$value) =3D each(%$opts)) {
+ $schema->{params}->{$key} =3D $value;
+ }
- return $schema unless @_;
- return $schema->parse( shift ) ? $schema : undef;
+ if ($arg) {
+ return $schema->parse( $arg ) ? $schema : undef;
+ }
+ return $schema;
}
sub _error {
@@ -38,7 +88,10 @@
return undef;
}
+ # PM: save schema options before resetting schema and restore them=20
afterwards
+ my $params =3D $schema->{params};
%$schema =3D ();
+ $schema->{params} =3D $params;
my $entry;
if( ref $arg ) {
@@ -484,6 +537,21 @@
my @tokens;
pos($val) =3D 0;
+ if ($schema->{params}->{novellkludge})
+ {
+ push @tokens, $+
+ while $val =3D~ /\G\s*(?:
+ ([()])
+ |
+ ([^"'\s()]+)
+ |
+ "(.*?)"(?=3D[\s)])
+ |
+ '(.*?)'(?=3D[\s)])
+ )\s*/xcg;
+ }
+ else
+ {
push @tokens, $+
while $val =3D~ /\G\s*(?:
([()])
@@ -494,6 +562,7 @@
|
'([^']*)'
)\s*/xcg;
+ }
die "Cannot parse [$val] ",substr($val,pos($val)) unless @tokens a=
nd=20
pos($val) =3D=3D length($val);
# remove () from start/end
Yours
Peter
--=20
Peter Marschall | eMail: pet...@ma...
Scheffelstra=DFe 15 | pet...@is...
97072 W=FCrzburg | Tel: 0931/14721
PGP: D7 FF 20 FE E6 6B 31 74 D1 10 88 E0 3C FE 28 35
|
|
From: Graham B. <gb...@po...> - 2002-01-10 15:35:04
|
On Wed, Jan 09, 2002 at 10:12:46PM +0100, Peter Marschall wrote:
> Hi,
>
>
> On Tuesday 08 January 2002 17:21, you wrote:
> > An interesting question. It would make parsing rather interesting. You are
> > right that the RFC does not disallow this. Net::LDAP assumed that no
> > sensible person would do that (like many apps assume no sensible person
> > puts spacing in filenames :)
> Who says they are sensible (maybe they just forgot quoting/escaping ;-))
>
> > If you can provide a schema (or subset of one) with this I will see what I
> > can do.
> Of course, here it is for the single quotes and the undescores
> (line breaking manually done by me):
>
> attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
> X-NDS_NAME 'New Object's DS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
> X-NDS_NAME 'New Object's FS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
> DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE
> X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
Hm...
> > > Last but not least, I have a very rough patch available that would allow
> > > to parse such a schema. But I have to polish it a bitbefore I send it.
> > > Are you interested ?
> > Sure. Don't spend too much time polishing it before letting others test it.
> > Just a correct patch is fine, it can be polished later.
> I warned you, it is very rough ;-)
> More a very dirty kludge than a patch.
> Its a unified diff againts perl-ldap 0.25 and atleast the
> part in LDAP.pm violates the RFC that defined the
> "vendorName" attribute in the roodDSE.
> The RFC vedorName must not be used to change the
> behaviour of applications. A better solution might be to
> defined a global ldap option "alternate_schema_parser".
> (the better parts of the code are shamelessly stolen from
> other parts of perl-ldap ;-)
I would rather just not have to know where the schema came from and
have the parser DTRT
Graham.
|
|
From: Graham B. <gb...@po...> - 2002-01-10 15:58:42
|
On Wed, Jan 09, 2002 at 10:12:46PM +0100, Peter Marschall wrote:
> Hi,
>
>
> On Tuesday 08 January 2002 17:21, you wrote:
> > An interesting question. It would make parsing rather interesting. You are
> > right that the RFC does not disallow this. Net::LDAP assumed that no
> > sensible person would do that (like many apps assume no sensible person
> > puts spacing in filenames :)
> Who says they are sensible (maybe they just forgot quoting/escaping ;-))
>
> > If you can provide a schema (or subset of one) with this I will see what I
> > can do.
> Of course, here it is for the single quotes and the undescores
> (line breaking manually done by me):
>
> attributeTypes: ( 2.16.840.1.113719.1.55.4.1.1 NAME 'newObjectSDSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.17
> X-NDS_NAME 'New Object's DS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.56.4.1.1 NAME 'newObjectSFSRights'
> DESC 'Standard Attribute' SYNTAX 2.16.840.1.113719.1.1.5.1.15{64512}
> X-NDS_NAME 'New Object's FS Rights'
> X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
> attributeTypes: ( 2.16.840.1.113719.1.57.4.1.1 NAME 'setupScript'
> DESC 'Standard Attribute' SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE
> X-NDS_NAME 'Setup Script' X-NDS_NOT_SCHED_SYNC_IMMEDIATE '1' )
Actually, if you read the RFC it states that a qdstring is
qdstring = whsp "'" dstring "'" whsp
Note that there is leading, and trailing whitespace. So teh above can be parsed
simply by changing one line in Schema.pm That is
'([^']*)'
to
'((?:[^']+|'\S)*)'
and now the above parses fine
Graham.
|
|
From: Chris R. <chr...@me...> - 2002-01-10 16:11:49
|
Graham Barr <gb...@po...> wrote:
> Note that there is leading, and trailing whitespace. So teh above can be
> parsed
Oh no there isn't!
whsp = [ space ]
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2002-01-10 16:21:56
|
On Thu, Jan 10, 2002 at 04:11:34PM -0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > Note that there is leading, and trailing whitespace. So teh above can be > > parsed > > Oh no there isn't! > > whsp = [ space ] Right, I missed that. Well I will stick with the assumtion until it is proved to cause a problem, or the definition is fixed. Graham. |
|
From: Chris R. <chr...@me...> - 2002-01-10 16:23:27
|
Peter Marschall <pet...@ma...> wrote: > I warned you, it is very rough ;-) > More a very dirty kludge than a patch. > Its a unified diff againts perl-ldap 0.25 and atleast the > part in LDAP.pm violates the RFC that defined the > "vendorName" attribute in the roodDSE. RFC 3045, I think. > The RFC vedorName must not be used to change the > behaviour of applications. A better solution might be to > defined a global ldap option "alternate_schema_parser". I think we should just have one parser that only uses the attributeTypes (etc) attributes, but modified so that it works with these odd values (which as is pointed out later on, are technically legal.) Cheers, Chris |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X