Ben Collins-Sussman writes:
> We have an architecture that looks like
>
> client app --> libsvn_client --> libsvn_ra
>
> The arrows indicate the direction of function calls. As a matter of
> principle, we don't want an RA library to directly call some
> libsvn_client routine (or client app routine) like
> prompt_for_passphase(). It breaks the layered design if we start
> allowing circular dependencies.
I guess I'm not clear on why this is such an iron principle. Even if it
adds a circular dependency -- I'm not really sure what you mean by that --
that's orthogonal to the layered design concern, isn't it? Why can't
something with circular dependencies have a layered design?
> Instead, the RA library returns a set of flags to libsvn_client which
> indicates what kind of authentication info it needs. Then it's up to
> libsvn_client, and perhaps it's caller, to get the info.
I think perhaps what I was thinking isn't very different from what you
propose, only I think of the server being in control -- after all it knows
what it needs and when so why shouldn't it drive the transaction? I also
see it as possibly being a series of exchanges rather than a simply "here
are the fields that need to be filled in" single exchange. For instance,
I'm not sure how an authentication method that relied on a series of
challenges and responses would be implemented with the method you described.
But that might just be lack of imagination on my part :-)
> But a single "opaque shared secret" -- is that enough?
I don't see why not. It's really just an index into a matrix of actions and
whether they are allowed or not. The matrix would be constructed at
authentication time by the RA. After authentication it doesn't matter how
many pieces of information were required to generate the matrix. But I
think maybe I'm misunderstanding something and the client session handle is
all you really need. I guess it just seems like you only need the user
authentication information to set up the permission matrix. After that's
done the info is not only superfluous but potentially damaging, given that
for at least some authentication schemes it will contain a cleartext
password, isn't it?
Justus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006