Forum: Ruby Net::LDAP filters

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-15 15:18
(Received via mailing list)
Hello

Excuse me if this is a dumb question but I searched the docs and
couldn't find a way to do this... Is there any method that converts an
LDAP filter string to a filter object to be used in #search, ie,
something like

"uid=foo" being understood as Net::LDAP::Filter.eq("uid", "foo")

?

Thanks in advance,
Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 15:37
(Received via mailing list)
I assume by "LDAP filter string" you mean an RFC-2254 compliant string,
correct?
Net::LDAP intentionally avoided supporting this kind of textual
representation of filters, partly because they're ugly and partly
because
they don't map to anything in the LDAP wire protocol.

However, we've thought about adding methods that would convert
Net::LDAP::Filters to and from RFC-2254 strings. Would that help you? Is
it
because you have these strings lying around in existing code? Are you
trying
to port from an application that uses the native-LDAP wrapper library?
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-15 15:53
(Received via mailing list)
Hi Francis

On Mon, 2006-05-15 at 22:37 +0900, Francis Cianfrocca wrote:
> However, we've thought about adding methods that would convert
> Net::LDAP::Filters to and from RFC-2254 strings. Would that help you? Is it
> because you have these strings lying around in existing code? Are you trying
> to port from an application that uses the native-LDAP wrapper library?

I'm writing a script to allow me to work with ldap without having to
deal with the ldap* tools that come with openldap and are a pain to use.
So what I need is some way to let the user provide search filters from
the command line, and these would ideally be RFC-2254 strings, since
that's what people are used to deal with, despite being ugly...

These conversion methods would surely be very useful for that.

Regards,
Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 16:21
(Received via mailing list)
I'll tell you what: if we add these methods and send you a
pre-release, would you be willing to beta-test them against some of
your own strings?
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-15 16:30
(Received via mailing list)
On Mon, 2006-05-15 at 23:20 +0900, Francis Cianfrocca wrote:
> I'll tell you what: if we add these methods and send you a
> pre-release, would you be willing to beta-test them against some of
> your own strings?

Sure, I'd be glad to test it!

Thanks,
Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 16:39
(Received via mailing list)
Ok, will email you when done.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-15 22:11
(Received via mailing list)
Andre, I have a new gem for you to test. It has version 0.0.1.1, which
we
won't release on Rubyforge. I'm going to email the gem directly to you
to
avoid polluting this mailing-list, but if you can confirm this does what
you
want, then I'll release it for everyone as version 0.0.2.

Net::LDAP::Filter now has the class method #from_rfc2254. (Ugly name,
may
change it.)

Instead of:
f = Net::LDAP::Filter.eq( "uid", "george*" )
you can now say:
f = Net::LDAP::Filter.from_rfc2254( "uid=george*")

All the compound expressions and conditionals are also supported, so do
some
testing and let me know if it's what you needed.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-16 21:15
(Received via mailing list)
Andre, thanks for testing and confirming the fix. It will be in the
next release of Net::LDAP. We added a class method to
Net::LDAP::Filter called #from_rfc2254, which takes a standard LDAP
filter string and returns a Net::LDAP::Filter object. We may rename it
to something more graceful before the release.

I'll think about your suggestion that we provide the same
functionality as an overload to Net::LDAP::Filter#new.

Regarding #search: this method currently does return a full result set
(an array of the entries returned by the search) whether or not you
provide a block. If you provide a block, then each entry is *also*
passed to the block. I think this is the flexibility you were looking
for in your question.

The reason we provided the :return_result flag to #search is so you
can turn off the generation of a result-set array. The flag defaults
to true, meaning the default behavior is both to return a result set
and to call a user-supplied block (if present) for each result. If you
set :return_result to false, then the results will only be passed to
your block, and discarded by Net::LDAP after each one is processed.
The point of being able to turn off the result set is to save memory
when the set is very large. The performance improvement is potentially
very large.

Thanks again for the testing you did.
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-16 21:32
(Received via mailing list)
On Wed, 2006-05-17 at 04:14 +0900, Francis Cianfrocca wrote:
> The point of being able to turn off the result set is to save memory
> when the set is very large. The performance improvement is potentially
> very large.

Yeah, I understand that. What I suggested was that the decision to
return the full result set can depend only on wether a block is passed
or not, like

results = ldap.search(...) # no block, return full result set

or

ldap.search(...) { |entry|  ... } # a block was given, return nil
                                  # (like File#open, for example)

That is, only return the result set if no block is given. I suggested
this because when you process each entry on the block you usually don't
use the result set returned anyway. Unless there's some situation where
you need to do

results = ldap.search(...) { |entry| ... }

then I see why the flag is useful, but I couldn't think of a situation
where I'd need that.


> Thanks again for the testing you did.

Thank you for the great lib and the quick support!

Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-16 21:38
(Received via mailing list)
Ah, I see the point. Interesting. I guess you're right, you probably
wouldn't need the array if you were supplying a block! Maybe we'll keep
the
:return_result flag but default it to false when a block is given.

Did you have any other problems with the unreleased version of the
library
that I sent you? There's actually a lot of new behavior in there that
hasn't
been documented yet :-). (We're trying to make the LDAP API a lot more
streamlined and intuitive.)
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-16 21:48
(Received via mailing list)
On Wed, 2006-05-17 at 04:37 +0900, Francis Cianfrocca wrote:
> Did you have any other problems with the unreleased version of the library
> that I sent you? There's actually a lot of new behavior in there that hasn't
> been documented yet :-). (We're trying to make the LDAP API a lot more
> streamlined and intuitive.)

No problems here, but I only did testing with #search and #replace.
Everything worked fine.

Andre
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-17 21:22
(Received via mailing list)
On Wed, 2006-05-17 at 04:47 +0900, Andre Nathan wrote:
> On Wed, 2006-05-17 at 04:37 +0900, Francis Cianfrocca wrote:
> > Did you have any other problems with the unreleased version of the library
> > that I sent you? There's actually a lot of new behavior in there that hasn't
> > been documented yet :-). (We're trying to make the LDAP API a lot more
> > streamlined and intuitive.)
>
> No problems here, but I only did testing with #search and #replace.
> Everything worked fine.

I've noticed that the attribute names are downcased when they're
returned in a search result (for example, 'shadowFlag'
becomes :shadowflag). Couldn't this cause problems with duplicate
attribute names? (I'm assuming LDAP is case-sensitive but I actually
don't know).

Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-17 21:56
(Received via mailing list)
LDAP attribute names are usually not case-sensitive. I had a couple of
reasons for handling those the way I did, but I can be persuaded
otherwise!
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-17 22:40
(Received via mailing list)
On Thu, 2006-05-18 at 04:54 +0900, Francis Cianfrocca wrote:
> LDAP attribute names are usually not case-sensitive. I had a couple of
> reasons for handling those the way I did, but I can be persuaded
> otherwise!

Well, my only argument is that if I search for something, I'd expect
that the return result to include the same attribute name that I
searched for.

It's nothing overly important, I was just writing some unit tests and
was surprised to see that results[:shadowFlag] was nil, so I had to dump
the whole results to find out the key is actually :shadowflag.

Andre
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-17 22:59
(Received via mailing list)
I addressed that in a different way, which may or may not be ideal. The
object which comes back from #search has methods defined on it to match
the
attributes that were returned. And the method names are
case-insensitive.
You ought to able to say result.shadowFlag and get the result you
expect.
Try it.
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (Guest)
on 2006-05-17 23:09
(Received via mailing list)
I thought about it some more and I realized you're right. The original
motivation for returning canonical attribute names was that there's no
guaranteeing what an LDAP server will actually return (in regard to case
of
attribute names), so I figured it would be least surprising to the
programmer to get back a standard form (all lower-case). That probably
does
make sense when you don't specify which attributes you want back. But it
doesn't make any sense otherwise, especially given that a core goal of
Net::LDAP is to hide the messiness of the LDAP wire protocol. I'm going
to
change the code accordingly, and I appreciate your suggestion.
8b4249ca3bb8c123da9f7aca63a652e1?d=identicon&s=25 Andre Nathan (Guest)
on 2006-05-18 03:23
(Received via mailing list)
On Thu, 2006-05-18 at 06:07 +0900, Francis Cianfrocca wrote:
> I'm going to
> change the code accordingly, and I appreciate your suggestion.

Thanks! (again! :)

Andre
This topic is locked and can not be replied to.