"Justus Pendleton" <subversion@ryoohki.net> writes:
> > The issue here is that an RA library cannot directly prompt the
> > user for information -- like a password.
>
> But the client only needs to support four or five methods and the RA library
> can indirectly prompt for whatever information it desires. I'm not sure I
> see a huge difference between directly prompting and indirectly promting
> only one step removed.
I'm not sure what you're proposing...?
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.
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.
> > * create a transparent svn_ra_user_t structure.
> >
> > This structure contains the *union* of all authentication data
> > needed by all RA implementations. (There's no way around this.)
>
> I don't follow why there is no way around this, maybe you can explain?
> Wouldn't some opaque shared secret (that doesn't contain possibly sensitive
> authentication data) work just as well? That way potentially sensitive data
> isn't just sitting around in memory and isn't being sent across the wire
> with every action requested? And that way you don't need to stick a
> potentially large svn_ra_user_t structure in the baton, only about 20 bytes
> of fingerprint.
We're certainly not *requiring* that the user_t structure be stored in
the RA session baton, nor do we know if the authentication is going to
happen on every request. It's more probable that an RA layer (after
authenticating the first RA request) stores an expiration-timed cookie
or something in the session baton. Whatever it wants to do -- it's
not the client's business. The client merely has an opaque "session"
object with the RA library that it can reuse.
Certainly, after the client creates the user_t structure and exchanges
it for a session baton, it has no need to hang on to the user_t
struct. It can free it, so the sensitive data is no longer just
hanging around in memory.
But a single "opaque shared secret" -- is that enough? What if some
RA layer needs 4 pieces of information. Should we create a new opaque
struct for that RA layer and then teach all client libraries how to
fill it in? I suppose we could. It just seems easier to add fields
to the user_t structure instead. Is there a disadvantage to this?
---------------------------------------------------------------------
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