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 pathsI 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 --
smime.p7s
Description: S/MIME Cryptographic Signature
