[Vortex] SASL authentication callback object passing

[Milton YATES]

Le lundi 05 juin 2006 à 08:35 +0200, Francis Brosnan Blazquez a écrit :
> > when one creates a listener, one provides callbacks for channel
> > start / stop / frame_received events and one can provide a void*
> > pointer which is passed as parameter to the callback.
> > This is quite useful, especially because I use C++ and I'm not able to
> > use objects without a pointer.
> > 
> 
> Ok.
> 
> > On the other hand, I've noticed that vortex_sasl_set_*_validation()
> > functions does NOT provide such "pointer passing" functionality, which
> > is really a shame, as I think it would be as much useful to have this
> > functionality for the sasl auth callbacks, as it is for the channel
> > creation callbacks.
> > 
> > The situation is, I have some kind of "main" object handling
> > connections and user informations, and I can only validate a user I
> > can access this object and for that, I would need the "trick" of
> > passing an object pointer to the callback you used with the channel
> > creation callback.
> > 
> 
> Sure. You can use the key-indexed store associated to the connection
> that is being authenticated. See the following functions:
> 
>     - vortex_connection_set_data [1]
>     - vortex_connection_get_data [2]
> 
> You can even define a key-associated destructor function, allowing to
> store different user application data, that is deallocated in a
> particular way:
> 
>    - vortex_connection_set_data_full [3]
> 
> The same functionality is provided at the channel level. However,
> because you are authenticating the whole connection, I think you are not
> interested to use this.

I have seen these alright, but how can I use them in the case described?
Do I have access to the new connection anywhere before it gets to the
SASL authentication? My understanding is that there is no way.
If I wanted to do this, I would need to have access to the new
connection BEFORE the SASL auth (the VortexSaslAuth* callback), set_data
on the connection, then let it go to the SASL auth and get_data again on
the connection. My understanding for now is that you cannot access the
connection before the SASL auth is completed, which is a good thing btw
^^.
Correct me if I'm wrong, or if there actually IS a way, besides
patching :\

> > Could you change the API in this respect ?
> 
> Only to clarify the Vortex API/ABI policy. Once a public API is exposed
> through an stable release, it is never modified in future releases. If
> the problem doesn't get solved because it is really required to change
> the API, an alternative API is added, flagging as deprecated the
> previous one.

I fully understand your concern. But this problem may really be a
mistake in the first place, because you had all the elements in the code
to do this pointer passing trick
(vortex_profiles_register_extended_start provides a user_data parameter)
and unfortunately you did not use the opportunity :(

I have created a patch to support this,
-- it changes the callback signatures (of course, it adds a gpointer
user_data), which is really bad for API compatibility that's for sure.
-- it adds one parameter (user_data) to vortex_sasl_accept_negociation.
This modification can be made transparent for the API by using a default
value for the parameter, or creating a function override.

Bye.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 200 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.aspl.es/pipermail/vortex/attachments/20060605/079bd986/attachment.pgp