Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87744 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72196 invoked from network); 13 Aug 2015 15:32:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Aug 2015 15:32:26 -0000 Authentication-Results: pb1.pair.com smtp.mail=andreas@heigl.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=andreas@heigl.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain heigl.org from 195.191.240.18 cause and error) X-PHP-List-Original-Sender: andreas@heigl.org X-Host-Fingerprint: 195.191.240.18 hos109.unaxus.net Received: from [195.191.240.18] ([195.191.240.18:45100] helo=hos109.unaxus.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id ED/76-00702-888BCC55 for ; Thu, 13 Aug 2015 11:32:25 -0400 Received: from 80-219-169-28.dclient.hispeed.ch ([80.219.169.28]:22569 helo=wdv-hg-0C07-zX4090-HeiglAndreas.local) by hos109.unaxus.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZPuUO-002X2a-7P; Thu, 13 Aug 2015 17:32:20 +0200 To: Rainer Jung , PHP internals References: <5582BC3E.30109@opensides.be> <55C8FFF9.40509@kippdata.de> <2E228E18-2AC9-4FA5-AB11-4F7C3365EB0B@heigl.org> <55C92754.8040308@kippdata.de> <55CA0DAD.8010405@opensides.be> <55CB2749.2020809@kippdata.de> <1D4FAD35-B39D-48B0-AC68-546F945AD067@heigl.org> <55CCAC0E.50008@kippdata.de> Cc: =?UTF-8?Q?C=c3=b4me_BERNIGAUD?= X-Enigmail-Draft-Status: N1110 Message-ID: <55CCB888.1050605@heigl.org> Date: Thu, 13 Aug 2015 17:32:24 +0200 MIME-Version: 1.0 In-Reply-To: <55CCAC0E.50008@kippdata.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000909050400060800000202" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hos109.unaxus.net X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - heigl.org X-Get-Message-Sender-Via: hos109.unaxus.net: authenticated_id: a.heigl+heigl.org/only user confirmed/virtual account not confirmed Subject: Re: [PHP-DEV] LDAP module requirements? From: andreas@heigl.org (Andreas Heigl) --------------ms000909050400060800000202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rainer. Am 13.08.15 um 16:39 schrieb Rainer Jung: > Am 12.08.2015 um 13:17 schrieb Andreas Heigl: >> Hi Rainer. >> >>> Am 12.08.2015 um 13:00 schrieb Rainer Jung := >>> >>> Hi C=F4me, >>> >>>> Am 11.08.2015 um 16:58 schrieb C=F4me BERNIGAUD: >>>>> On 2015-08-11 00:36, Rainer Jung wrote: >>>>> The current problems should be mostly around the above four compile= r >>>>> warnings. I can test any patches you want me to test. >>>> >>>> Can you test including the attached file in ext/ldap/ldap.c, and not= >>>> defining HAVE_3ARG_SETREBINDPROC and LDAP_CONTROL_PAGEDRESULTS ? >>> >>> thanks for the patch proposal. There's a few problems with it and I >>> will come back to you with an alternative proposal soon. For the mome= nt: >>> >>> >>> - the definition of ldap_control_find in terms of at the top of >>> ldap.c currently is protected by >>> >>> #if !defined(HAVE_LDAP_CONTROL_FIND) >>> >>> It should be >>> >>> #if defined(LDAP_CONTROL_PAGEDRESULTS) && >>> !defined(HAVE_LDAP_CONTROL_FIND) >>> >>> That's not related to your patch. >>> >>> >>> - in >>> >>> void ldap_memvfree( void **value ) >>> { >>> ldap_value_free(value); >>> } >>> >>> >>> it should probably be >>> >>> ldap_value_free((char **)value); >>> >>> otherwise we get compiler warnings. >>> >>> >>> - instead of ldap_open() we can use ldap_init() (recommended). >>> >>> >>> - using ldap_open() or ldap_init() with a url does not work, we have >>> to use host and port. >>> >>> >>> - the use of ldap_sasl_bind_s() in PHP_FUNCTION(ldap_bind) does not >>> work, without setting "LDAP_OPT_PROTOCOL_VERSION" to LDAP_VERSION3 >>> using ldap_set_option(). Maybe it works for OpenLDAP, but Netscape >>> and Solaris document it must be set and indeed return >>> LDAP_NOT_SUPPORTED immediately otherwise. But since in >>> PHP_FUNCTION(ldap_bind) no SASL functionality is actually being used,= >>> I propose to use ldap_simple_bind_s() instead of ldap_sasl_bind_s(). >>> It is not deprecated and using it actually simplifies the code a bit.= >>> >>> >>> As I said, I'll come up with a patch proposal soon. >>> >>> The patch should also help for other LDAP implementations than >>> OpenLDAP or Solaris. >>> >> The main question here is whether we want PHP to support other >> implementations. The documentation clearly states that OpenLDAP shall >> be used and even Oracle states on an official site (I don't actually >> have the URL at hand but it has been in an email to this thread) that >> PHPs LDAP extension has to be built against OpenLDAP. >=20 > That's you (project) call. You are doing the work, you decide. I > wouldn't rely on Oracle for a judgement ;) We should all decide (somehow) ;) And thanks for the warning about Oracle= ;) >=20 > Also note that the code and m4 macros have quite a few places where the= y > react on other LDAP SDKs, like Windows, Oracle (not sun) and I think > also Netware. But those are not really strong arguments for multi-SDK > support. You can purge those places and the argument is gone. I really > think it depends on your goals. >=20 > But you should consider 5.6 a stable release. Maybe I'm the only guy on= > the planet haven't build the ldap extension against non-OpenLDAP, but I= > doubt it. 7.0 is in front of the doors and compatibility is much less a= n > issue there, maybe combined with a NEWS entry strengthening, that you > now really demand OpenLDAP and throw an error, if you can't find it > during configure. You are actually right on that one. We should keep BC in the 5.6 release. That was the reason for the call to what other libs are used where no one stepped up for others and therefore there wasn't any BC expected.... :( @C=F4me, can we fix that in the 5.6 branch somehow? >=20 >> Come has done a great job to clean up the LDAP code to start >> implementing long awaited features and I'm not really sure whether we >> should give that up for maintaining compatibility with some edge-case >> usages. So I'm very interested in your patch to see how we can rech >> both goals! >=20 > Agreed, and much of the cleanup wouldn't have to be undone to make the > result still compatible with more SDKs. For instance all of the new use= > of the "_ext" variants of functions is nice and OK also for other LDAP > implementations. That's great! I'm not that deep into the C-business (yet) therefore I'll need a day or two to digest the patch. I'd just love to see the LDAP-extension move towards better implementation of such things as paginated and/or serversided sorted results. Thanks for your input and contribution! Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=B022'59.5" E 08=B023'58"= | | http://andreas.heigl.org http://hei.gl/wiFKy7 | +---------------------------------------------------------------------+ | http://hei.gl/root-ca | +---------------------------------------------------------------------+ --------------ms000909050400060800000202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC BawwggWoMIIDkKADAgECAgMPT+kwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTQwNzIzMDkzMjQ5WhcNMTYwNzIyMDkzMjQ5WjBcMRYwFAYDVQQDEw1BbmRyZWFzIEhlaWds MSAwHgYJKoZIhvcNAQkBFhFhLmhlaWdsQGhlaWdsLm9yZzEgMB4GCSqGSIb3DQEJARYRYW5k cmVhc0BoZWlnbC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCn6XLcWFLD vAXgllUikBAU2Rv63m7ZKP+ZU/2HTWDW0BJ2muK7GD3cGZxbKKosO6l6PSqqmLqUJ8G6b/85 iPQmNL5z+LG/+wt/p31SOMAWc5UA7CJAQ9pivUCcV+Yt0LzoxWO5ME2rEZ/ioB2tXMilkJLM U4f5A9m3YZVSKj3xbM7rIpQEZiK0TrZ4MchTwPMdAwBLBxCoAztcg4Yj4qKd+IQLff0Ldhc5 3tc9b+XT7YzWLY5rQKHE+hKqIAdvYfqqKQZFHBBXptSXUXBeYK5a4UT0fpnMP7toqr/9mLlK +FvDNeVwSo5I/abiqdek1lH0/xwYy9im8k4SRtLTAp7hAgMBAAGjggFUMIIBUDAMBgNVHRMB Af8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9y IEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMC A6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3 CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2Nz cC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9y ZXZva2UuY3JsMC8GA1UdEQQoMCaBEWEuaGVpZ2xAaGVpZ2wub3JngRFhbmRyZWFzQGhlaWds Lm9yZzANBgkqhkiG9w0BAQ0FAAOCAgEAlG1bUuar9u5ONtedFR7UHp7MNa5Lnu+VzQ6IQAg+ ghXlHdLqU2V2R8BaWCFlaCCkGqX8Od5Z0XpAKfHlfbVMV7vRZBqhnzwe28+QqcI47pzawaBo DFNjS138orZEOPW88S8JcTsoUfy57U7z/4tSjYwCFKmLFQLLPWt/TzhrPWCgdg5PANSTELnH YGy5cA66pbGRp9B/ofHOpAxW4mQPGPEcXHZpkkna4034PkPKGyGg24YTqS+0zVPrXiEemKY8 f7vuSnvnHTQc61Ubk091UGI0dUUJeEncEDR1G5uTzTLdk+5/J6O2CA3gpCMjmAdly7p2WzrX 9LEWJ5f+VvkE/NzerPZyOdC1HTRvQAHkpxewyg4u8MHjBhakVXBLzOVSoEOd6ttSvquSyUU/ 1hhDuKZaz3kBnGpyhlnY3ZqN7mhF15XcD//C8kKAe6rDF7+asKIQV59GAkyeTSBGFt0eceqQ bD/gcGWWfPZK6jTLVFvr1eXERLF9MPoA0+JdfpzjfC9shfVfAjLBI97MGKzpXBR8B9GT+ieY yUM101/vsb6mne6nTtj9cIf74S4T6yEFL5+Oi2JsVDgh0mSKNiFLfZvLFJOfyF2KctGIS1Jv mjJU8CznFdd7Z9psgoaXk2HwvgJXkfKBCW1RdrzdyXrGVymqEyGVqiG5gZ0iC1ZfFRcxggOx MIIDrQIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNh Y2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG 9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDD0/pMA0GCWCGSAFlAwQCAQUAoIICATAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MTMxNTMyMjRaMC8G CSqGSIb3DQEJBDEiBCBX2ih6fHrvuB/j+Xqlzhl6OrbRph0RWW5luuUto35N+zBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3 dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJ KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAw9P6TCBkwYLKoZIhvcNAQkQAgsxgYOg gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3Jn MSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJz dXBwb3J0QGNhY2VydC5vcmcCAw9P6TANBgkqhkiG9w0BAQEFAASCAQAmOrrr+qDec1rtYuH0 lo4Z9BRoZEItnSCRTAUZewWd5NKWfU0ZQiktMTUJpxf7uFxDtMB1X+Ng/t41IJzRdEDwMCoA G153+GbDTakkjVeudlbOi3mncHRpX+mFgeD5y1J5Z15XsXgoL6NEuLTxTO1yiUdp5OZHXLfQ Al+33Dfgj5nKizoVpZvatRGqqJX4ev4hsPBFpqHOK3TfpL8WlZA2F+jiOpvHPYC3MsOi6ajS YJAYrsN+vpaJNvXujSLLXk1loQOsSH86HARA57rygW2DJeVFd/IhB9N0gohepCMRaXZY9wOT AcFuskpEgG/wVz128GTqm976bXA6MKDhAkaAAAAAAAAA --------------ms000909050400060800000202--