[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

auth cache (was: svn commit: rev 5006 - in trunk/subversion: include libsvn_ra_dav libsvn_auth)

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-02-22 11:50:03 CET

On Fri, Feb 21, 2003 at 10:10:04PM -0600, cmpilato@collab.net wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > 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".

Euh... sure, maybe the *whole* thing doesn't need to be reverted, but the
concept is not going to work. So the reply to the commit is one of:

1) revert it
2) look... look... ok. revert this, that, and this piece

Guess which I chose? :-)

If there are pieces that can still work in an environment where the
credentials are keyed from the runtime params, then fine... leave that in.
I'm not too fussed.

> > 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.

Yup, thx. I figured this one out after backtracking through the messages a
bit, and finding the thread on auth caching.

> 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.

Right. Assuming the *same* server issues the *same* challenge. That isn't
happening here, though, which is the problem.

> And do understand that this change did not happen without a bulk of
> debate and argument amonst the Chicago Three. :-)

Please don't "play that card". Of course I know you guys talked about this,
but it doesn't suddenly make all other arguments irrelevant simply because
two or three of you discussed the problem. Should I return the statement and
say, "I've been programming for 25 years [so you should listen to me]" ?

It is simply that I would guess that you guys discussed more of the
mechanics, yet missed the part about runtime parameterization of the
returned credentials? It's easy to miss; as I mentioned in my note, those
params are a bit global-ish, and that makes data flow analysis [and
consideration of that] a real bitch.

> 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.

Sure, it isn't that big of a deal. And asking for a revert isn't that big a
problem either.

I simply suggested a revert, then to figure out a new way to deal with those
extra keys, and move forward again. Personally, I'd say that the problem is
a bit too complex -- you don't know which params are part of the key. Thus,
it seems best left to the app to install a provider which understands the
environment and how to best cache credentials.

Consider this scenario:

  * working copy with portions from server A and server B
  * make changes to both parts
  * commit the WC
    - server A asks for a user/pass
    - auth fetches them and sends them to A
    - trundle along, commit to B
    - server B asks for a user/pass
    - auth returns the cached user/pass and sends them to B
    - um. oop. did we just send A's password to B? damn...

My request for a revert wasn't as knee jerk as it sounded :-) And in any
case, we get to have discussion before reversion, rather than some yahoos
jumping in and reverting without any talk... (*)


(*) there are certain, um, "other communities" that get a bit ugly with
their vetoes; discussion is considered optional... bleh... glad we don't
live in one, and I only have to deal with that one peripherally...

Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 22 11:46:17 2003

This is an archived mail posted to the Subversion Dev mailing list.