Re: sasl_utils_t->getopt() and options availability (or lack) at client side

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Francesco Grossi ITQL wrote:

Hi all

Hi Francesco,

Own-made plugin needs a specific option to be known at plug_init time (on both client and server sides). We put our option (mymech_opt1:value) in the sasl2/appl.conf file in order to have its value available by means of sasl_utils_t ->getopt() callback.

We operate like digestmd5 does with its DIGEST-MD5 option and it works as expected though only on the server side.

The value returned by the client glue code is null.

Thus we’ve been obliged to “hard read” the client config file.

We have more than a suspect that sasl_utils_t->getopt can’t do much more about it since sasl2 options are stored in a applicationname-dependent config file: because of sasl_client_init has not application-name among its parameter (as sasl_server_init does) the glue code is not application aware (on the client side).

Is our interpretation correct? Are we missing something?

You are correct - client side SASL code can't read an application specific configuration file.

However, I am thinking that you should be able to install your own getopt callback when calling sasl_client_init(), which should address your issue. Please try this and let me know if you find any issues.

Hopefully we would suggest a future valid alternative to have mechanism options available at client side.

Many thanks

Francesco Grossi




[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux