Re: ldap->ping?

[David B. <d.b...@ma...>]

Hi all (again),

>> containing functions/objects/whatever that query the ldap server to find
>> out what it's capable of?
>> ie:
>> is it "up"? - with an anonymous bind
>> is is "up"? - with a malformed packet request
>
>Do you really want to give the user control over what type of check to do ?

Why not... the best API is one that is simple to use with plenty of
defaults, but open enough to allow the user to use advanced options if they
prefer/require...  That's also the perl way of thinking isn't it?  I think
Marks suggestion is great, allow an optional call back, default to a decent
one(or more) if it's not provided... like:

Net::LDAP::isUp($ldap,[callback =>\&callback|callback
=>'anonymous'|callback =>'malformed']). 

>IIRC, This is all avaliable from the root DSE. But I guess you are looking
>for a simpler approach than
>
>  $dse = $ldap->root_dse;
>  $dse->get('supportedVersions'); # I forget the attribute name

The fact that you forget the attribute name is a perfect reason for
allowing a simpler approach.

I'm hopeless at remembering standard attribute names,etc..and why should I
have to?  If it's used frequently enough, include it as an option/default.
eg: $dse->getSupportedVersions();
I know in this case the code is trivial, and probably not a good candidate
for it, but you see my point don't you?

>> P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
>> of a simple "foolproof" API that is smart enough to figure out things like
>> the ldap version to talk with(currently 3 falling back to 2),
>
>You should bind to the version of which feature you need. If you don't use
>version 3 features bind as version 2. If you want v3 feature, falling back
to binding as
>v2 is the wrong thing to do.

What if I have the situation where I would prefer a secure connection to
keep away potential prying eyes, but I want the connection to succeed even
if that's not possible. (ie prefer a ssl connection using the version 3
protocol, but be happy to fall-back to version 2 on an unencrypted channel
if I have no other option) 

I'm big on fail-safes and fall backs..I like scripts to keep on working no
matter what goes wrong.... 

>> whether ssl
>> is supported on the server end (with a fall-back if its not),
>
>This is dangerous. If you want SSL it is normally for a reason, so falling
>back is REALLY the wrong thing.

As above, I like scripts to keep on working no matter what goes wrong.
Which is worse.. having thousands of users that can't log in because a
script failed to update their LDAP settings (sorry attributes) correctly,
or having a potentially unsecure connection to do it?    I guess it depends
on the situation.

>
>> if searches
>> are limited then automatically do multiple searches invisibly, etc etc.
>
>The Net::LDAPiranah module did this but I don't think it works with the
>latest version. But we will get it going again.

I'd Love to see it as an advanced option to the standard search function/s.

my 2c.
David.





--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------