You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2006/06/03 13:45:50 UTC
Re: svn commit: r411306 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
On 6/2/06, bnicholes@apache.org <bn...@apache.org> wrote:
> Author: bnicholes
> Date: Fri Jun 2 15:01:53 2006
> New Revision: 411306
>
> URL: http://svn.apache.org/viewvc?rev=411306&view=rev
> Log:
> Fix a problem with invalid auth error detection for LDAP client SDKs that don't support LDAP_SECURITY_ERROR macro. PR#39529
Should we define our own macro which uses LDAP_SECURITY_ERROR or the
more detailed logic, to keep the mainline code cleaner and support
reuse in other paths?
Re: svn commit: r411306
- /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
Posted by Brad Nicholes <BN...@novell.com>.
>>>> Graham Leggett <mi...@sharp.fm> 6/4/2006 2:42 AM >>>
>Brad Nicholes wrote:
>
>>> Should we define our own macro which uses LDAP_SECURITY_ERROR or
the
>>> more detailed logic, to keep the mainline code cleaner and support
>>> reuse in other paths
>>
>> I thought about that and couldn't really decide if we should define
the
>> LDAP_SECURITY_ERROR macro in the ldap header in apr-util or not. I
>> finally decided that if we started down that road then there are
>> probably a lot more macros and other differences between the LDAP
SDKs
>> and how far should we take it. So rather than try to redefine all
of
>> the missing macros and force a dependancy on between httpd and
>> apr-util, I would just solve it in authnz_ldap. We could certainly
>> rethink this and try to solve it in apr-util instead.
>
>apr_util already defines a number of macros for the purposes of
>standardising them, particularly for the SSL/TLS stuff where every
LDAP
>toolkit insisted on doing it differently, so we have already gone down
>that road.
>
>Standardising the macros is one thing that apr_util helps with to make
>LDAP access toolkit independent.
>
>The best solution IMHO is to add APU_LDAP_something to apr_util
>depending on how the different toolkits handle LDAP_SECURITY_ERROR
(Does
>this macro mean security error?). Will have to look at the different
>toolkits to work out what "something" should be.
>
>In the mean time though the patch is reasonable as is, it can be
changed
>once apr_util is patched and another apr_util is released.
>
>Regards,
>Graham
>--
+1, I'll add a new macro to apr-util and call it
APU_LDAP_SECURITY_ERROR. With the patch that is currently in place in
authnz_ldap, we can add the APU macros now and then remove the
authnz_ldap patch at a latter time once a new APR-Util has been
released. I think the basic differences between the SDKs is whether the
macro exists or not. Also from what I could see, there seemed to be a
naming difference between the Microsoft SDK and the others with the
#define LDAP_INSUFFICIENT_RIGHTS vs. LDAP_INSUFFICIENT_ACCESS. This can
be easily handled in the APU macro as well.
Brad
Re: svn commit: r411306 - /httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
Posted by Graham Leggett <mi...@sharp.fm>.
Brad Nicholes wrote:
>> Should we define our own macro which uses LDAP_SECURITY_ERROR or the
>> more detailed logic, to keep the mainline code cleaner and support
>> reuse in other paths
>
> I thought about that and couldn't really decide if we should define the
> LDAP_SECURITY_ERROR macro in the ldap header in apr-util or not. I
> finally decided that if we started down that road then there are
> probably a lot more macros and other differences between the LDAP SDKs
> and how far should we take it. So rather than try to redefine all of
> the missing macros and force a dependancy on between httpd and
> apr-util, I would just solve it in authnz_ldap. We could certainly
> rethink this and try to solve it in apr-util instead.
apr_util already defines a number of macros for the purposes of
standardising them, particularly for the SSL/TLS stuff where every LDAP
toolkit insisted on doing it differently, so we have already gone down
that road.
Standardising the macros is one thing that apr_util helps with to make
LDAP access toolkit independent.
The best solution IMHO is to add APU_LDAP_something to apr_util
depending on how the different toolkits handle LDAP_SECURITY_ERROR (Does
this macro mean security error?). Will have to look at the different
toolkits to work out what "something" should be.
In the mean time though the patch is reasonable as is, it can be changed
once apr_util is patched and another apr_util is released.
Regards,
Graham
--
Re: svn commit: r411306 -
/httpd/httpd/trunk/modules/aaa/mod_authnz_ldap.c
Posted by Brad Nicholes <bn...@novell.com>.
>>> On 6/3/2006 at 5:45 AM, in message
<cc...@mail.gmail.com>, "Jeff
Trawick"
<tr...@gmail.com> wrote:
> On 6/2/06, bnicholes@apache.org <bn...@apache.org> wrote:
>> Author: bnicholes
>> Date: Fri Jun 2 15:01:53 2006
>> New Revision: 411306
>>
>> URL: http://svn.apache.org/viewvc?rev=411306&view=rev
>> Log:
>> Fix a problem with invalid auth error detection for LDAP client SDKs
that
> don't support LDAP_SECURITY_ERROR macro. PR#39529
>
> Should we define our own macro which uses LDAP_SECURITY_ERROR or the
> more detailed logic, to keep the mainline code cleaner and support
> reuse in other paths
I thought about that and couldn't really decide if we should define the
LDAP_SECURITY_ERROR macro in the ldap header in apr-util or not. I
finally decided that if we started down that road then there are
probably a lot more macros and other differences between the LDAP SDKs
and how far should we take it. So rather than try to redefine all of
the missing macros and force a dependancy on between httpd and
apr-util, I would just solve it in authnz_ldap. We could certainly
rethink this and try to solve it in apr-util instead.
Brad