From: Trejkaz <trejkaz@...>
Date: 2006-02-28T07:53:38+09:00
Subject: Re: Authenticating distributed Ruby

> If your communications is of the (essentially) non-connected variety,
> example being HTTP, I don't see getting around passing an access "key"
> with each call.

Well, this depends on how you look at HTTP.

In the case of Rails, the majority of deployments seem to use FastCGI,
which keeps its instances up 24/7.  Those instances could easily stay
connected to the DRb server as long as there is some way to
authenticate when they first connect.  I'm fine with having to
authenticate for each connection, which is what my above solution was
all about (of course, it was only concept... a proper version would, as
you say, use a session ID and hashing to authenticate so that even if
someone snooped the conversation, they wouldn't get the real password.)

What I'm more worried about is whether a connection could connect, get
a reference to the remote object, disconnect, and then connect and
without authenticating, forge a direct method call to the object they
remembered from before.

It's almost like the hash which contains their password needs to be
used as part of the remote ID mapping.  That would be one way to
prevent this sort of memory, though I'm not entirely sure how to go
about it (YET... I've been reading drb.rb a lot lately. ;-))

I did get authentication working using SSL client certs last night,
generating them with QuickCert which is, BTW, extremely nice for this
sort of prototyping work.  But the problem is that as far as I can
tell, my remote object can't determine which client certificate was
passed in.  So it's nice and simple for authentication, as long as you
want every connection to have access to everything.  But maybe that's
okay for now.

TX