No, because lots of stuff is hidden. Consider what you have todo today
$mesg = $ldap->delete(@args);
handle_referal($mesg) if (... check for referral ..);
vs
$ldap = Net::LDAP-.new(..., referral_connect => \&my_connect)
$mesg= $ldap->delete(@args);
Where referrals are done behind the
Chris Ridd wrote:
Net::LDAP should not be caching credentials. Any caching should be down to
the caller.
By caller do you mean the the script or module that is actually calling
a function such as $ldap->modify()? If this what you mean, would
optionally passing the credentials in the function
On 16 Dec 2003, at 19:42, Chris Ridd wrote:
On 16/12/03 7:25 pm, Graham Barr <[EMAIL PROTECTED]> wrote:
It came up recently. My suggestion is that the user should be able to
register a callback with Net::LDAP that Net::LDAP will call when it
needs a connection to a different server. It would pass
On 16/12/03 9:41 pm, David Syzdek <[EMAIL PROTECTED]> wrote:
>
>> How would you handle authenticating to the other servers? Net::LDAP
>> deliberately does not cache authentication credentials, so it wouldn't be
>
> Couldn't this be overcome by caching the credentials in a hash if
> following ref
How would you handle authenticating to the other servers? Net::LDAP
deliberately does not cache authentication credentials, so it wouldn't be
Couldn't this be overcome by caching the credentials in a hash if
following referrals was enabled. To prevent Net::LDAP from caching
credentials needless
On 16/12/03 7:25 pm, Graham Barr <[EMAIL PROTECTED]> wrote:
> It came up recently. My suggestion is that the user should be able to
> register a callback with Net::LDAP that Net::LDAP will call when it
> needs a connection to a different server. It would pass the URL details
> from the referral and
On 16 Dec 2003, at 19:10, Chris Ridd wrote:
On 16/12/03 8:39 am, David Syzdek <[EMAIL PROTECTED]> wrote:
Are there plans to expand add(), delete(), moddn(), and modify() to
follow referrals?
Not especially, but if a clean design was suggested then I'm sure it
would
be considered.
I am currently
On 16/12/03 8:39 am, David Syzdek <[EMAIL PROTECTED]> wrote:
> Are there plans to expand add(), delete(), moddn(), and modify() to
> follow referrals?
Not especially, but if a clean design was suggested then I'm sure it would
be considered.
> I am currently following referrals by checking for ($
On 16/12/03 7:06 am, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> Hello,
> following perl script, using Net::LDAP 0.30 , sometimes causes following
> problem :
> ---
> $ldap = Net::LDAP->new(') or &DEBUG("Failed to open LDAP
> connection : $@");
> $ldap->bind
On 15/12/03 9:24 pm, D.Kreft <[EMAIL PROTECTED]> wrote:
> So I'm busily working away making "optimizations" to my code, but now when
> I try to start_tls(), I get the dreaded "unsupported extended operation"
> error. I googled for "Net::LDAP 'unsupported extended operation'" and
> saw a reply fro
> -Original Message-
> From: Norbert Klasen
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 12, 2003 2:50 PM
> To: _BA-Zentralamt-Maildienste; [EMAIL PROTECTED]
> Subject: Re: range-upper/range-lower
>
[...]
> These fields are not included in the attributeTypes (rfc
> 22552) attrib
Are there plans to expand add(), delete(), moddn(), and modify() to
follow referrals?
I am currently following referrals by checking for ($ldap->code == 10)
and making a second LDAP connection. Being able to pass new() an
additional parameter that instructs Net::LDAP to follow referrals would
Hello,
following perl script, using Net::LDAP 0.30 , sometimes causes following
problem :
---
$ldap = Net::LDAP->new(') or &DEBUG("Failed to open LDAP
connection : $@");
$ldap->bind or &DEBUG("Failed to bind to LDAP : $@");
&DEBUG("LDAP connection opened ") ;
13 matches
Mail list logo
