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

[Alexey Melnikov]

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
>