Re: ANONYMOUS SASL profile

[Francis Brosnan Blazquez]

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!

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


> > But as a result from previous call I get the following:
> >
> > "Anonymous auth requested: 'U\x89\xe5\x83\xec\x18\x89]\xf8\xe8R\xea
> \xff
> > \xff\x81\xc3\x1e\xbb\x01'"
> >
> > The validation callback is set using gsasl_callback_set. 
> 
> That might happen if 'ctx' is the wrong type.
> 
> > Concrect questions could be:
> >
> > 1) How do I get current anonymous token received from the client
> side?
> > I've tried to translate it supposing that it is a base64 encoded
> string
> > but I didn't get the expected result.
> 
> You are using the right function, gsasl_property_get.
> 
> > 2) Do we need to create a new Gsasl context, using gsasl_init, for
> every
> > connection we want to authenticate and then create the Gsasl session
> > with gsasl_client_start/gsasl_server_start? Which is the intention
> on
> > having the context and the session separeted and being created for
> every
> > connection to authenticate? 
> 
> 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.

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. 

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?

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?

Simon, excuse me asking you non-related GSASL questions. It will be fine
if you don't reply to them.

Thanks for your attention!
(and obviously for your time!)

Cheers!!

[1] http://www.beepcore.org

> Thanks,
> Simon
> 
-- 
Francis Brosnan Blazquez <address@hidden>
Advanced Software Production Line, S.L.