Re: [coldsync-hackers] Design logic of Sync conduits

[Christophe Beauregard <christophe dot beauregard at sympatico.ca>]

On Wednesday 03 March 2004 09:45, Andrew Arensburger wrote:

> 	Since the PDA needs to be connected, you need to do the
> authentication in a Sync conduit. Of course, if the authentication
> fails, you don't want to send sensitive data to the PDA.
...
> 	The easiest way to implement this might be to add a field to
> the internal conduit queue, to store the exit status of each conduit
> (or -1 if it has not yet been run).
> 	One limitation of the above is if you have something like:
>
> 	conduit Fetch "Generic fetch" {
> 		path: /usr/local/bin/genericfetch;
> 		type: */*;
> 	}
> 	conduit Dump "Generic dump" {
> 		require: "Generic fetch";
> 		type: */*;
> 		path: /usr/local/bin/genericdump;
> 	}
>
> then the "require" line effectively asks, "has 'Generic fetch' _ever_
> run successfully?", rather than "has 'Generic fetch' run correctly _on
> the current database_?".
>
> 	This sort of linking would allow you to have a single generic
> "Authenticate" conduit that protects a whole range of other conduits.
>
> 	Okay, I've gone on long enough. Does anyone have any thoughts?

Seems both overly complicated and inflexible. Overly complicated because it 
moves something that I'd consider conduit logic into the configuration 
engine, and inflexible because you've only really got two states to play 
with... pass or fail.

I'd suggest adding the ability for conduits to pass "tokens" back to 
coldsync which then get passed on to further conduits.

Umm.... If you've ever used the "notes" method to pass data between mod_perl 
handlers, you'll know what I mean. In fact, that's exactly how I handle 
authentication in a mod_perl system. Essentially, coldsync itself just acts 
as an accumulator for whatever bits of info a conduit might want to pass to 
something else downstream without having to worry about interpreting the 
actual data.

From a conduit, generating a token could be as simple as:

	print "601 AuthToken=", md5_hex($ssh_key), "\n";

Okay, hide that behind ColdSync::WriteToken('AuthToken',$ssh_key).

With this, a typical authenticator sync would look like:

  StartConduit('sync');
  my $dbh = dlp_OpenDB( "MyKeyDB", 0x80 );
  my $record = dlp_ReadRecordByIndex( $dbh, 0, 0, -1 )
  	or EndConduit(401, 'Failed to get SSH key');
  WriteToken( 'SSHKey', $record->{'data'} )
  	if defined $record and defined $record->{'data'};
  EndConduit();

Conduits further along the chain would receive the tokens like headers and 
preferences in the %TOKENS has... i.e.

	my $sshkey = read_key( "~/.ssh/id_dsa" );
	if( $TOKENS{'AuthToken'} eq $sshkey ) {
		sync_all_records();
	} else {
		sync_public_records();
	}

The advantage here is that conduits are completely in control of what gets 
passed around and how they react when things go bad. Furthermore, by 
providing the actual token data, you can do some pretty sophisticated 
access control lists or whatever funky logic you'd like.

You also get more data channels than with a simple exit code. One apps wants 
to use ssh keys and another wants to use PalmOS security passwords? No 
problem. One wants to just send along the pathname to the database that the 
user is allowed to sync with (i.e. "/home/user1/.palm/backup/blah.pdb" vs 
"/var/share/palmbackup/public_blah.pdb")? No problem.

Pretty simple to code up, too.

c.

This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.