Garrett Rooney <rooneg@electricjellyfish.net> writes:
> Ben Collins-Sussman wrote:
>
> >Robert Pluim <rpluim@bigfoot.com> writes:
> >
> >
> >>Ben Collins-Sussman writes:
> >> > The only thing I can think of is to do what Philip suggested about
> >> > svn_client_add() -- make *all* the svn_client_foo() functions take a
> >> > *list* of targets. That way everything can happen in a single RA
> >> > session. > > Of course, what if the user runs 'svn ls URL1 URL2
> >> URL3', and URL2
> >> > happens to be a different server? Ugh.
> >>
> >>Well, wouldn't svn_client_ls just prompt if needed for URL2, and reuse
> >>the auth stuff it's cached from URL1 for URL3?
> >>
> >
> >I think you're missing the point. There IS no more caching
> >mechanism. :-)
> >
>
> huh? we've still go the auth baton, assuming that they used the same
> client context, so why can't we cache the authentication stuff there,
> keyed off of repos uuid (once we have those working anyway).
Ah! Now *there's* a caching solution that might work. gstein, this
fixes the security problem, doesn't it? Is keying off the repos uuid
enough, or are there other runtime params we need to worry about?
Assuming uuid->auth_cache hash lives in the client_ctx_t, then we can
write a provider that looks in there, and make sure the provider is
registered first in the list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 24 15:18:35 2003