Greg Stein <gstein@lyra.org> writes:
> On Fri, Feb 21, 2003 at 12:20:08PM -0600, sussman@tigris.org wrote:
> > Author: sussman
> > Date: 2003-02-21 12:19:39 -0600 (Fri, 21 Feb 2003)
> > New Revision: 5006
> >
> > Modified:
> > trunk/subversion/include/svn_auth.h
> > trunk/subversion/libsvn_auth/auth.c
> > trunk/subversion/libsvn_ra_dav/session.c
> > Log:
> >
> > Implement a simple caching system in libsvn_auth (and simplify/cleanup
> > some stuff in the process.)
> >
> > Now the same auth_baton can be used over and over with multiple
> > svn_client_foo() calls, and each subsequent RA session will receive
> > cached creds when it calls first_creds().
>
> Nope... please revert.
>
> Recall that fetching credentials of a specific kind is *also* keyed by
> parameters that may have been set using svn_auth_set_parameter(). If the RA
> layer sets a Basic Auth Realm, then asks for credentials, it does *not* want
> credentials come from some other realm.
This alone hardly seems a reason to revert the whole change! I mean,
Ben has added functional middle-ground between "what was" and "what
should be".
> What is the basis for this change? Why was a cache needed? Maybe we
> can find a different way to solve what you were trying to fix.
The problem was that if a client performed multiple commit-y tasks in
a single execution of the program (think GUI client), and caching was
disabled, each commit operation would force an auth prompt. That was
broken. After the first prompt, we should still hang onto the creds
in memory so that prompting only has to happen once per program
execution. In other words, make all valid sets of creds have the same
lifetime as the master auth baton.
And do understand that this change did not happen without a bulk of
debate and argument amonst the Chicago Three. :-) In the end, no
solution was a great one (and we thought of many), but the one Ben
went with was the agreed-upon best of the bunch.
Seems he just forgot that there's one more level of keying going on --
not that big a deal, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 07:12:17 2003