I think we need to move the lutil_sasl_interact stuff into libldap. Clients ought to be able to use libldap's SASL support without having to #include Cyrus's <sasl.h> themselves. Right now they're forced to write their own interact handlers and the handlers must know about the SASL_CB constants etc. This is ugly; callers shouldn't need to know anything about what the underlying SASL implementation is doing.
Actually the lutil_sasl_ code should be cleaned up a bit, not used in libldap as-is. In particular, we should define a callback whose only purpose is to display a provided prompt string and retrieve user input. This callback's interface must have zero dependencies on <sasl.h>. We can provide a generic callback that writes to stderr and uses getpassphrase, but callers should be able to replace this with GUI dialog callbacks etc.
Howard Chu wrote:
I think we need to move the lutil_sasl_interact stuff into libldap.
Good idea.
Clients ought to be able to use libldap's SASL support without having to #include Cyrus's <sasl.h> themselves. Right now they're forced to write their own interact handlers and the handlers must know about the SASL_CB constants etc. This is ugly; callers shouldn't need to know anything about what the underlying SASL implementation is doing.
I agree.
Actually the lutil_sasl_ code should be cleaned up a bit, not used in libldap as-is. In particular, we should define a callback whose only purpose is to display a provided prompt string and retrieve user input. This callback's interface must have zero dependencies on <sasl.h>. We can provide a generic callback that writes to stderr and uses getpassphrase, but callers should be able to replace this with GUI dialog callbacks etc.
Yes, this is sensible.
-
Alexey Melnikov -
Howard Chu