Re: ANONYMOUS SASL profile

[Simon Josefsson]

Francis Brosnan Blazquez <address@hidden> writes:

> El mié, 14-12-2005 a las 10:29 +0100, Simon Josefsson escribió:
>
> Hi Simon,
>
>> > anonymous_token = gsasl_property_get (ctx, GSASL_ANONYMOUS_TOKEN);
>> > g_print ("Anonymous auth requested: %s\n", anonymous_token);
>> 
>> What type is 'ctx'?  It must be of the Gsasl_session type, not Gsasl.
>> 
>
> This was the problem. I was using the Gsasl context where the Gsasl
> session was expected. It works fine!

Great!

> What I don't understand is why gcc didn't drop me an error. I'll check
> it.

It should have...

>> The idea is the have one Gsasl context per application, and one
>> Gsasl_session for each client/server session in the application.  This
>> is to make it as lightweight as possible.
>> 
>> Creating a Gsasl context for each session is slightly more expensive,
>> but compared to everything else I think it is very minor.  The extra
>> time will be in gsasl_init, and setting any global callbacks.
>> 
>> There is no problem in creating multiple Gsasl contexts in an
>> application, if that would simplify your design.
>> 
>
> Well, I think we have to check what we are doing here because we where
> getting some seg faults while reusing the same Gsasl context. That's why
> we started to use a context (Gsasl *) and a session (Gsasl_session *)
> for each connection.

Ok.  There shouldn't be any problem.  You will get crashes if you use
Gsasl* instead of Gsasl_session*, perhaps you have other such errors?

GNU SASL should also be thread safe for any normal use.  You can't
invoke gsasl_step* for the same Gsasl_session in two threads at the
same time, but I don't consider that normal use.

> Simon, thanks for your clear and quickly reply. 
>
> BTW, we are using GSASL for the BEEP stack [1] we are working on. You
> could find it at: http://vortex.aspl.es. 

Thanks, I added a link to it on the GSASL home page.

> Now that I have you at the other side let me ask you another question
> not directly related to GSASL. 
>
> For win32 buildings which compiler/product are you using? The product we
> actually use is mingw. Are you using this also?

Yes.  I am using mingw32 as distributed by Debian.

> I asking you this because we are having some annoying issues while
> producing native dll on windows that is not produced with gcc. Actually,
> gcc automatically (well, allows you) to export all symbols from your
> library into the dll. But using other product such us Visual Studio you
> need to do the standard voodo with dllimport/dllexport attributes (or
> using G_MODULE_EXPORT from Glib which actually bounds to the same) or
> especify a module definition (.def file).
>
> But reading how GSASL headers are written I've found that you are using
> "extern" attribute rather than any non-sense stuff such as
> G_MODULE_EXPORT.
>
> Our intention is to keep on using gcc (through mingw) to support Vortex
> Library on win32, but it would be great to also support products such as
> VS. The main problem with VS is that not providing dllimport/dllexport
> stuff (or a .def file) cause not producing the import library (.lib). As
> you know, this actually allows Win32 ISVs to link with the dll produced.
>
> How did you work around this issue on windows for GSASL?

Currently I only support mingw32, not VS.  If you can provide details
on how to fix this in GSASL, I'll be happy to install any patches.
Supporting VS seem like a useful thing, if doesn't cause any harm to
anything else.

Some web searching revealed this:

http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/#dll-magic
http://stud3.tuwien.ac.at/~e9725344/gtk/Building_HowTo.html

Perhaps it can be of any help...

Thanks,
Simon