Re: TLS profile

Andrea Campi <[email protected]> writes:

> On Thu, Jul 25, 2002 at 04:52:17PM +0200, Jonas Borgstr?m wrote:
> > 
> > > So, right now, the only way to authenticate an initiator is to use
> > > SASL, correct?
> > > 
> > 
> > Yep
> > 
> 
> Thanks. Another question, then. How do I make sure clients
> authenticate first?
> 
> I tried using start_indication, but it doesn't seem to be called.
> If I do the check in start_confirmation, it will work, but this
> is already late, as by then rr_cap_start() will have already returned
> success.
> 
> Besides, what is the right way to do this?
> 
> 		rr_manager_close_channel_nonblock(manager,
> 				channel,
> 				RR_BEEP_CODE_AUTH_REQUIRED, NULL,
> 				"You must authenticate first", 
> 				&error);
> 

The start_indication name was a bit confusing, this is why it is called
client_init in the cvs version.

The easiest way for the server side to make sure the client is authenticated
before the channel is allowed to start is probably to add this code into
the server_init function:

if (not_authenticated) {

        g_error_set (error, RR_BEEP_ERROR, RR_BEEP_CODE_AUTH_REQUIRED,
                     "You must authenticate first");
        return FALSE;
}

This would stop the channel from being created and an error frame
with the error message will be sent to the initiator peer.

server_init was known as "validate_piggyback" in the 0.8 release.

The api change is basically that some virtual functions are renamed
and their arguments changed.

start_indication -> client_init
reply_piggyback  -> client_confirmation
validate_piggyback -> server_init
start_confirmation -> server_confirmation

And that the RRProfile type is removed and the profile specific
functions and members are moved into RRChannel.

/ Jonas
-- 
Jonas Borgström                  [email protected]
CodeFactory AB                   http://www.codefactory.se/
Office: +46 (0)90 71 86 10       Cell: +46 (0)70 248 89 58