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... (*)
Cheers,
-g
(*) 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