From: Graham B. <gb...@po...> - 2001-10-24 14:22:19
|
----- Forwarded message from Todd Woods <tw...@di...> ----- Date: Wed, 24 Oct 2001 09:18:20 -0500 (CDT) To: gb...@po... From: Todd Woods <tw...@di...> Subject: perl-ldap and multiple start_tls errors Couldn't find anything using google on this error so e-mailing you. 8) I can't start more then 1 LDAP bind using start_tls in a perl script. It errors out from IO::Socket::SSL when issuing start_tls on the subsequent ldap objects event if I do an unbind first. Reading under IO::Socket::SSL I noticed that it mentions you can only have one SSL context at a given time. I've seen scripts (haven't run them though) where an ssl socket was opened/closed multiple times in a script. So wondering if this is a problem with perl-ldap. Does an unbind request in perl-ldap close the underlying IO:Socket:SSL created when a start_tls method is invoked on an ldap object? Thanks, Todd ----- End forwarded message ----- |
From: Chris R. <chr...@me...> - 2001-10-24 15:14:15
|
Graham Barr <gb...@po...> wrote: > ----- Forwarded message from Todd Woods <tw...@di...> ----- > > Date: Wed, 24 Oct 2001 09:18:20 -0500 (CDT) > To: gb...@po... > From: Todd Woods <tw...@di...> > Subject: perl-ldap and multiple start_tls errors > > Couldn't find anything using google on this error so e-mailing > you. 8) > I can't start more then 1 LDAP bind using start_tls in a perl > script. It errors out from IO::Socket::SSL when issuing start_tls on the > subsequent ldap objects event if I do an unbind first. > Reading under IO::Socket::SSL I noticed that it mentions you can > only have one SSL context at a given time. I've seen scripts (haven't run Yeah, I saw that too. I suspect that only having a single SSL context means you can only have a single SSL connection at a time. > them though) where an ssl socket was opened/closed multiple times in a > script. So wondering if this is a problem with perl-ldap. I'm not sure that opening/closing an SSL socket is really what you want to do, but if you can you point us at the scripts which do this that might give us more info. > Does an unbind request in perl-ldap close the underlying > IO:Socket:SSL created when a start_tls method is invoked on an ldap > object? No, the socket only gets closed when the $ldap object gets destroyed. In practice, that's when the $ldap variable goes out of scope. > Thanks, > Todd > > > ----- End forwarded message ----- > Cheers, Chris |
From: Graham B. <gb...@po...> - 2001-10-24 15:35:35
|
On Wed, Oct 24, 2001 at 04:13:43PM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > ----- Forwarded message from Todd Woods <tw...@di...> ----- > > > > Date: Wed, 24 Oct 2001 09:18:20 -0500 (CDT) > > To: gb...@po... > > From: Todd Woods <tw...@di...> > > Subject: perl-ldap and multiple start_tls errors > > > > Couldn't find anything using google on this error so e-mailing > > you. 8) > > I can't start more then 1 LDAP bind using start_tls in a perl > > script. It errors out from IO::Socket::SSL when issuing start_tls on the > > subsequent ldap objects event if I do an unbind first. > > Reading under IO::Socket::SSL I noticed that it mentions you can > > only have one SSL context at a given time. I've seen scripts (haven't run > > Yeah, I saw that too. I suspect that only having a single SSL context means > you can only have a single SSL connection at a time. IO::Socket::SSL does create a new context each time, but it stores it in a global. I wonder it the problem is that on the second connect the refcount for the first context goes to zero and it is freed, thus causing problems for Net::SSLeay on the inital connection. It may be worth trying to save the contents of $IO::Socket::SSL::SSL_Context_obj, after calling context_init, in the ldap object. Graham. |
From: Graham B. <gb...@po...> - 2001-10-24 15:51:02
Attachments:
ssl.pat
|
On Wed, Oct 24, 2001 at 04:31:08PM +0100, Graham Barr wrote: > On Wed, Oct 24, 2001 at 04:13:43PM +0100, Chris Ridd wrote: > > Graham Barr <gb...@po...> wrote: > > > ----- Forwarded message from Todd Woods <tw...@di...> ----- > > > > > > Date: Wed, 24 Oct 2001 09:18:20 -0500 (CDT) > > > To: gb...@po... > > > From: Todd Woods <tw...@di...> > > > Subject: perl-ldap and multiple start_tls errors > > > > > > Couldn't find anything using google on this error so e-mailing > > > you. 8) > > > I can't start more then 1 LDAP bind using start_tls in a perl > > > script. It errors out from IO::Socket::SSL when issuing start_tls on the > > > subsequent ldap objects event if I do an unbind first. > > > Reading under IO::Socket::SSL I noticed that it mentions you can > > > only have one SSL context at a given time. I've seen scripts (haven't run > > > > Yeah, I saw that too. I suspect that only having a single SSL context means > > you can only have a single SSL connection at a time. > > IO::Socket::SSL does create a new context each time, but it stores it in > a global. I wonder it the problem is that on the second connect the > refcount for the first context goes to zero and it is freed, thus causing > problems for Net::SSLeay on the inital connection. > > It may be worth trying to save the contents of $IO::Socket::SSL::SSL_Context_obj, > after calling context_init, in the ldap object. OK, this is a hack, but it seems to work around the limitation in IO::Socket::SSL Graham. |
From: Graham B. <gb...@po...> - 2001-10-29 16:55:46
|
Did anyone else try this ? I know it is a hack, but do others think we should include it ? Graham. On Wed, Oct 24, 2001 at 04:46:32PM +0100, Graham Barr wrote: > On Wed, Oct 24, 2001 at 04:31:08PM +0100, Graham Barr wrote: > > On Wed, Oct 24, 2001 at 04:13:43PM +0100, Chris Ridd wrote: > > > Graham Barr <gb...@po...> wrote: > > > > ----- Forwarded message from Todd Woods <tw...@di...> ----- > > > > > > > > Date: Wed, 24 Oct 2001 09:18:20 -0500 (CDT) > > > > To: gb...@po... > > > > From: Todd Woods <tw...@di...> > > > > Subject: perl-ldap and multiple start_tls errors > > > > > > > > Couldn't find anything using google on this error so e-mailing > > > > you. 8) > > > > I can't start more then 1 LDAP bind using start_tls in a perl > > > > script. It errors out from IO::Socket::SSL when issuing start_tls on the > > > > subsequent ldap objects event if I do an unbind first. > > > > Reading under IO::Socket::SSL I noticed that it mentions you can > > > > only have one SSL context at a given time. I've seen scripts (haven't run > > > > > > Yeah, I saw that too. I suspect that only having a single SSL context means > > > you can only have a single SSL connection at a time. > > > > IO::Socket::SSL does create a new context each time, but it stores it in > > a global. I wonder it the problem is that on the second connect the > > refcount for the first context goes to zero and it is freed, thus causing > > problems for Net::SSLeay on the inital connection. > > > > It may be worth trying to save the contents of $IO::Socket::SSL::SSL_Context_obj, > > after calling context_init, in the ldap object. > > OK, this is a hack, but it seems to work around the limitation in IO::Socket::SSL > > Graham. > Index: lib/Net/LDAP.pm > =================================================================== > RCS file: /cvsroot/perl-ldap/ldap/lib/Net/LDAP.pm,v > retrieving revision 1.27 > diff -u -u -r1.27 LDAP.pm > --- lib/Net/LDAP.pm 2001/10/22 12:32:33 1.27 > +++ lib/Net/LDAP.pm 2001/10/24 15:48:45 > @@ -789,7 +789,12 @@ > > require Net::LDAPS; > $arg->{sslversion} = 'tlsv1' unless defined $arg->{sslversion}; > + > + local $IO::Socket::SSL::SSL_Context_obj = 0; > IO::Socket::SSL::context_init( { Net::LDAPS::SSL_context_init_args($arg) } ); > + > + $ldap->{ssl_context} = $IO::Socket::SSL::SSL_Context_obj; > + > (IO::Socket::SSL::socketToSSL($sock) and tie *{$sock}, 'IO::Socket::SSL', $sock) > ? $mesg > : _error($ldap, $mesg, LDAP_OPERATIONS_ERROR, $@); |
From: Chris R. <chr...@me...> - 2001-10-29 17:00:53
|
Graham Barr <gb...@po...> wrote: > Did anyone else try this ? > > I know it is a hack, but do others think we should include it ? > > Graham. I'd personally prefer for IO::Socket::SSL to be corrected. Cheers, Chris |
From: Graham B. <gb...@po...> - 2001-10-29 17:22:06
|
On Mon, Oct 29, 2001 at 05:00:29PM -0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > Did anyone else try this ? > > > > I know it is a hack, but do others think we should include it ? > > > > Graham. > > I'd personally prefer for IO::Socket::SSL to be corrected. Sure, but do we work around it in the meantime ? Maybe I just include it as a patch Graham. |
From: Chris R. <chr...@me...> - 2001-10-29 17:32:00
|
Graham Barr <gb...@po...> wrote: > On Mon, Oct 29, 2001 at 05:00:29PM -0000, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > Did anyone else try this ? >> > >> > I know it is a hack, but do others think we should include it ? >> > >> > Graham. >> >> I'd personally prefer for IO::Socket::SSL to be corrected. > > Sure, but do we work around it in the meantime ? Yeah, why not. > Maybe I just include it as a patch I'd be inclined not to, as these may or may not get installed depending on how alert the installer is. It doesn't matter too much. I'm not too bothered either way. > Graham. Cheers, Chris |
From: Graham B. <gb...@po...> - 2001-10-29 18:15:30
|
I have made the release without the change. We can always give the patch tho those who ask Graham. On Mon, Oct 29, 2001 at 05:31:35PM -0000, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Mon, Oct 29, 2001 at 05:00:29PM -0000, Chris Ridd wrote: > >> Graham Barr <gb...@po...> wrote: > >> > Did anyone else try this ? > >> > > >> > I know it is a hack, but do others think we should include it ? > >> > > >> > Graham. > >> > >> I'd personally prefer for IO::Socket::SSL to be corrected. > > > > Sure, but do we work around it in the meantime ? > > Yeah, why not. > > > Maybe I just include it as a patch > > I'd be inclined not to, as these may or may not get installed depending on > how alert the installer is. > > It doesn't matter too much. I'm not too bothered either way. > > > Graham. > > Cheers, > > Chris > |
From: John B. <joh...@ne...> - 2001-11-15 17:30:57
|
Hello folks, Does anyone see any utility in adding support for Net::LDAP to query a local LDIF file as opposed to a directory? This would be for testing purposes, and I think could be made to work like this: - read-only. All add/modify etc operations fail - each search operation could simply re-scan all entries in the LDIF file sequentially and decide if the entry matched the search criteria. Then either add to the search result and/or fire any callbacks. Of course, this could be optimised but that isn't really the point. The point would be that for the (reasonably large?) class of problems which require read-only LDAP access, you could write and test Net::LDAP code against an LDIF image of a directory. Would patches to implement something like this be accepted (or would this be better as a seperately maintained subclass of Net::LDAP)? Does anyone see problems in doing this which I have missed [*]? Or is something like this already implemented and I've not noticed? regards, jb [*] - complications could include: a - authentication (probably either support simple auth only or always succeed) b - starttls [again probably just fake success] c - I haven't really thought through how complex the 'does this entry match these search criteria' decision would have to be. Filters can be complex. Will I need to handle different encodings of DNs and attribute names? |
From: Graham B. <gb...@po...> - 2001-11-15 17:44:57
|
This sounds like an excellent idea. But I think it should be a sub-class of Net::LDAP. In fact, if it was a package that understood the data structures passed to Convert::ASN1. Then it could have many uses. Your subclass you mention could just call it instead of encoding with Convert::ASN1. But we could also write a simple server that could be used for testing within the distribution. Graham. On Thu, Nov 15, 2001 at 05:30:38PM +0000, John Berthels wrote: > Hello folks, > > Does anyone see any utility in adding support for Net::LDAP to query a > local LDIF file as opposed to a directory? This would be for testing > purposes, and I think could be made to work like this: > > - read-only. All add/modify etc operations fail > > - each search operation could simply re-scan all entries in the LDIF file > sequentially and decide if the entry matched the search criteria. Then > either add to the search result and/or fire any callbacks. > > Of course, this could be optimised but that isn't really the point. > > > The point would be that for the (reasonably large?) class of problems > which require read-only LDAP access, you could write and test Net::LDAP > code against an LDIF image of a directory. > > Would patches to implement something like this be accepted (or would this > be better as a seperately maintained subclass of Net::LDAP)? > > Does anyone see problems in doing this which I have missed [*]? > > Or is something like this already implemented and I've not noticed? > > regards, > > jb > > > [*] - complications could include: > > a - authentication (probably either support simple auth only or always > succeed) > > b - starttls [again probably just fake success] > > c - I haven't really thought through how complex the 'does this entry > match these search criteria' decision would have to be. Filters can be > complex. Will I need to handle different encodings of DNs and attribute > names? > > |
From: Clif H. <ch...@po...> - 2001-11-20 04:28:46
|
I think this is a good idea. Clif Graham Barr wrote: > This sounds like an excellent idea. But I think it should be a sub-class > of Net::LDAP. > > In fact, if it was a package that understood the data structures > passed to Convert::ASN1. Then it could have many uses. > > Your subclass you mention could just call it instead of encoding > with Convert::ASN1. But we could also write a simple server that > could be used for testing within the distribution. > > Graham. > > On Thu, Nov 15, 2001 at 05:30:38PM +0000, John Berthels wrote: > > Hello folks, > > > > Does anyone see any utility in adding support for Net::LDAP to query a > > local LDIF file as opposed to a directory? This would be for testing > > purposes, and I think could be made to work like this: > > > > - read-only. All add/modify etc operations fail > > > > - each search operation could simply re-scan all entries in the LDIF file > > sequentially and decide if the entry matched the search criteria. Then > > either add to the search result and/or fire any callbacks. > > > > Of course, this could be optimised but that isn't really the point. > > > > > > The point would be that for the (reasonably large?) class of problems > > which require read-only LDAP access, you could write and test Net::LDAP > > code against an LDIF image of a directory. > > > > Would patches to implement something like this be accepted (or would this > > be better as a seperately maintained subclass of Net::LDAP)? > > > > Does anyone see problems in doing this which I have missed [*]? > > > > Or is something like this already implemented and I've not noticed? > > > > regards, > > > > jb > > > > > > [*] - complications could include: > > > > a - authentication (probably either support simple auth only or always > > succeed) > > > > b - starttls [again probably just fake success] > > > > c - I haven't really thought through how complex the 'does this entry > > match these search criteria' decision would have to be. Filters can be > > complex. Will I need to handle different encodings of DNs and attribute > > names? > > > > -- Regards, Clif Harden ch...@po... |
From: John B. <joh...@ne...> - 2001-11-27 19:31:40
Attachments:
LDAPL.pm.gz
|
> > This sounds like an excellent idea. But I think it should be a sub-class > > of Net::LDAP. > > > > In fact, if it was a package that understood the data structures > > passed to Convert::ASN1. Then it could have many uses. > > > > Your subclass you mention could just call it instead of encoding > > with Convert::ASN1. But we could also write a simple server that > > could be used for testing within the distribution. OK. I was trying to avoid ASN.1 entirely. An outline of what I intended is attached. (Only enough implemented to demonstrate the concept I had in mind - the search implementation currently matches everything in the LDIF). The idea is that (whilst testing away from a server) you can instantiate a Net::LDAPL (poor name I think) instead of a Net::LDAP and still test your app. Anyone sufficiently interested in this for me to finish it? regards, jb |
From: John B. <joh...@ne...> - 2001-11-28 08:22:53
|
For what its worth, I think that there are many environments where chasing referrals automatically is useful. IMHO an option to do so would be a useful enhancement to the module. jb |
From: Terry D. <td...@bi...> - 2001-11-28 08:26:42
|
agreed. it can be dangerous with auth stuff flying accross and should not be default behavior but that is why you said "option". :) John Berthels wrote: >For what its worth, I think that there are many environments where chasing >referrals automatically is useful. IMHO an option to do so would be a >useful enhancement to the module. > >jb > |
From: Graham B. <gb...@po...> - 2001-11-28 11:54:23
|
On Tue, Nov 27, 2001 at 07:31:21PM +0000, John Berthels wrote: > > > This sounds like an excellent idea. But I think it should be a sub-class > > > of Net::LDAP. > > > > > > In fact, if it was a package that understood the data structures > > > passed to Convert::ASN1. Then it could have many uses. > > > > > > Your subclass you mention could just call it instead of encoding > > > with Convert::ASN1. But we could also write a simple server that > > > could be used for testing within the distribution. > > OK. I was trying to avoid ASN.1 entirely. An outline of what I intended is > attached. (Only enough implemented to demonstrate the concept I had in > mind - the search implementation currently matches everything in the > LDIF). I was not suggesting that you actually use ASN.1, but the data structures that get passed to the Convert::ASN1 module. Then there is little work todo to create a subclass of Net::LDAP as you only have to override the send/recv instead of having to reimplement everything > The idea is that (whilst testing away from a server) you can instantiate a > Net::LDAPL (poor name I think) instead of a Net::LDAP and still test your > app. Sure. Graham. > Anyone sufficiently interested in this for me to finish it? > > regards, > > jb |