You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2003/02/22 04:10:04 UTC
Re: svn commit: rev 5006 - in trunk/subversion: include libsvn_ra_dav libsvn_auth
Greg Stein <gs...@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
Re: auth cache
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
>Greg Stein <gs...@lyra.org> writes:
>
>
>
>> * server A is CollabNet's server, holding SourceCast source
>> - access via https using your corporate password
>> * server B is svn.collab.net, holding Subversion source
>> - access via http using your svn.c.n password
>> * your working copy uses svn:externals to aggregate these two
>>
>>Now, you go to do a commit and enter your user/pass for CollabNet's servers.
>>It is nicely protected via https, all is good. Then svn goes to commit
>>against svn.collab.net and it sends your corporate password over the public
>>Internet in the clear via http:.
>>
>>See the problem? :-)
>>
>>
>
>Yeah, I see. Rats. Sigh, I'll revert. :-)
>
>So the original itch we were trying to solve was the fact that
>TortoiseSVN, a long-lived GUI client, had this long-lived auth_baton
>that was being re-used on svn_client_foo() calls. Every single call
>to svn_client_foo() was causing a prompt for creds. Do we have any
>other solutions to this problem?
>
>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.
>
ick. i really dislike that, it makes the client interface much more
complicated.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 24, 2003 at 08:58:47AM -0700, David Waite wrote:
> Ben Collins-Sussman wrote:
> >Garrett Rooney <ro...@electricjellyfish.net> writes:
> >>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?
>
> I think you need to key off of both the uuid and the server address;
> otherwise I can 'trick' your client to providing me your auth
> credentials for a specific server by manually setting the uuid to match ;-)
Right.
The appropriate set of things to feeding into any cache key is pretty
dependent upon the set of providers that you're using and what *their*
inputs are. That's why I don't think a general cache is going to work, but
one tuned to the particular environment.
Cheers,
-g
--
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
Re: auth cache
Posted by David Waite <ma...@akuma.org>.
Ben Collins-Sussman wrote:
>Garrett Rooney <ro...@electricjellyfish.net> writes:
>
>
>>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?
>
I think you need to key off of both the uuid and the server address;
otherwise I can 'trick' your client to providing me your auth
credentials for a specific server by manually setting the uuid to match ;-)
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache
Posted by Ben Collins-Sussman <su...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> Ben Collins-Sussman wrote:
>
> >Robert Pluim <rp...@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
Re: auth cache
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
>Robert Pluim <rp...@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).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Ben Collins-Sussman <su...@collab.net>.
Robert Pluim <rp...@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. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Robert Pluim <rp...@bigfoot.com>.
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?
Robert
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by mark benedetto king <mb...@boredom.org>.
On Mon, Feb 24, 2003 at 08:26:34AM -0800, Ben Collins-Sussman wrote:
>
> Ouch! Good point! At a minimum, our prompt provider needs to know
> the exact URL which is issuing the challenge, and tell the user. Wow.
>
Or some logical realm name, id, or something. I worry about URLs because
they are just references; there may be other lexically different and
semantically equivalent references. It is also possible (likely, in the case
of tunnelled HTTP connections) that the server's idea of its canonical
URL is different from the client's.
In addition to the realm name, we might also be interested in whether
the server has been somehow authenticated, and if so, how; there's no point
in sending our nice pretty credentials off to a Man-In-The-Middle.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Ben Collins-Sussman <su...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> I'm looking at the interface in svn_auth.h and I don't understand why
> svn_auth_first_credentials and svn_auth_next_credentials don't take an
> some sort of context/realm parameter, something that will identify the
> URL for which credentials are required.
>
> Does the current system ask for credentials without any reference to
> the URL? Is this information supposed to be transferred through the
> run-time hash?
The auth_baton's 'runtime parameter' hash isn't heavily used yet. No
auth provider is looking for a URL at runtime.
wc-provider: looks for a wc-dir/access-baton in the hash
all providers: look for --username, --password, --non-interactive,
--no-auth-cache in the hash.
I'm guessing that someday, the client-certs provider will look for
some kind of specific server-challenge data in the hash.
Furthermore, someday the wc-provider will instead become a
~./subversion/ provider, and data *will* be keyed off of UUID.
> It's not just a problem in the security case above, or for
> TortoiseSVN, it seems to be more fundamental. Consider external
> modules. At present I get prompted for a password on initial
> checkout, as a user I can reasonably guess that I need to supply one
> to match the top level URL I supplied. What then happens if there are
> multiple external modules from other repositories? I get further
> prompts for passwords and I appear to have no way to determine the URL
> for which I have to provide credentials.
Ouch! Good point! At a minimum, our prompt provider needs to know
the exact URL which is issuing the challenge, and tell the user. Wow.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Stein <gs...@lyra.org> writes:
> > multiple external modules from other repositories? I get further
> > prompts for passwords and I appear to have no way to determine the URL
> > for which I have to provide credentials.
>
> Right... we need a standard runtime param that the prompting provider can
> examine. The URL is the best thing that we have, pending a notion of a
> "repository human-readable name".
That "repository human-readable name" needs to be available *before*
the repository is checked out. If the URL is not the name then where
does the name come from? Is a round trip to the server, without
authentication, involved?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 24, 2003 at 02:09:15PM +0000, Philip Martin wrote:
>...
> I'm looking at the interface in svn_auth.h and I don't understand why
> svn_auth_first_credentials and svn_auth_next_credentials don't take an
> some sort of context/realm parameter, something that will identify the
> URL for which credentials are required. Does the current system ask
> for credentials without any reference to the URL? Is this information
> supposed to be transferred through the run-time hash?
The latter. And earlier, I mentioned something to Ben, and his response:
> > Currently, the auth interface has this "out of band" global-variable-like
> > thing where you set runtime parameters. That API makes a lot of sense for
> > configuration type stuff (e.g. the cmdline switches), but less sense for
> > true runtime params. For those, you would ideally have a hash that is passed
> > specifically to first_creds. Then it becomes obvious that your credential
> > fetching has additional inputs beyond "give me some of <these>"
>
> Sorry, I'm totally lost, not understanding what you're talking about
> anymore.
Your query and my followup to Ben is to consider the following two calls:
creds, iter = auth.first_cred(KIND, pool)
or
creds, iter = auth.first_cred(KIND, params, pool)
Which one is more obvious that the credential fetching is parameterized?
Today, we only have the former since the params are passed "out of band" via
the runtime hash. My comment above (to Ben) was simply my explanation on why
we ended up trying to cache stuff without consideratin of the params:
because it wasn't *obvious* that params are part of the equation. If we had
passed them as part of the first_cred() call, then it would have stuck out a
bit more, and the initial caching implementation might have tried to
consider them as part of the key.
>...
> multiple external modules from other repositories? I get further
> prompts for passwords and I appear to have no way to determine the URL
> for which I have to provide credentials.
Right... we need a standard runtime param that the prompting provider can
examine. The URL is the best thing that we have, pending a notion of a
"repository human-readable name".
Cheers,
-g
--
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
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
>
> > * server A is CollabNet's server, holding SourceCast source
> > - access via https using your corporate password
> > * server B is svn.collab.net, holding Subversion source
> > - access via http using your svn.c.n password
> > * your working copy uses svn:externals to aggregate these two
> >
> > Now, you go to do a commit and enter your user/pass for CollabNet's servers.
> > It is nicely protected via https, all is good. Then svn goes to commit
> > against svn.collab.net and it sends your corporate password over the public
> > Internet in the clear via http:.
> >
> > See the problem? :-)
>
> Yeah, I see. Rats. Sigh, I'll revert. :-)
>
> So the original itch we were trying to solve was the fact that
> TortoiseSVN, a long-lived GUI client, had this long-lived auth_baton
> that was being re-used on svn_client_foo() calls. Every single call
> to svn_client_foo() was causing a prompt for creds. Do we have any
> other solutions to this problem?
>
> 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.
I'll admit I kind of switched off during the long discussions about
the auth system :) If this has been discussed already just point me
at the archives
I'm looking at the interface in svn_auth.h and I don't understand why
svn_auth_first_credentials and svn_auth_next_credentials don't take an
some sort of context/realm parameter, something that will identify the
URL for which credentials are required. Does the current system ask
for credentials without any reference to the URL? Is this information
supposed to be transferred through the run-time hash?
It's not just a problem in the security case above, or for
TortoiseSVN, it seems to be more fundamental. Consider external
modules. At present I get prompted for a password on initial
checkout, as a user I can reasonably guess that I need to supply one
to match the top level URL I supplied. What then happens if there are
multiple external modules from other repositories? I get further
prompts for passwords and I appear to have no way to determine the URL
for which I have to provide credentials.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> * server A is CollabNet's server, holding SourceCast source
> - access via https using your corporate password
> * server B is svn.collab.net, holding Subversion source
> - access via http using your svn.c.n password
> * your working copy uses svn:externals to aggregate these two
>
> Now, you go to do a commit and enter your user/pass for CollabNet's servers.
> It is nicely protected via https, all is good. Then svn goes to commit
> against svn.collab.net and it sends your corporate password over the public
> Internet in the clear via http:.
>
> See the problem? :-)
Yeah, I see. Rats. Sigh, I'll revert. :-)
So the original itch we were trying to solve was the fact that
TortoiseSVN, a long-lived GUI client, had this long-lived auth_baton
that was being re-used on svn_client_foo() calls. Every single call
to svn_client_foo() was causing a prompt for creds. Do we have any
other solutions to this problem?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: auth cache (was: svn commit: rev 5006 ...)
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 22, 2003 at 10:07:38AM -0800, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>
> > * 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...
>
> Sorry, I'm confused. I think I'm dreadfully ignorant of security
> issues. Why is this a problem?
>
> The whole libsvn_auth design is based around the idea of repeatedly
> generating creds. Generate creds; if they fail to authenticate,
> try again; repeat until out of options.
>
> Why does it matter that we send A's password to B? Big deal, the
> creds don't work, so we start asking providers to generate them
> instead. We're just adding an extra 'attempt' before hitting the
> real providers, which may or may not work.
>
> Or is the real issue here that we need to treat B as a hostile server,
> and assume that it will remember any bad creds we ever send it? Is
> that what I'm missing?
Partly, yes, B could be hostile. But even more likely is the path to *get*
to server B.
Concrete example:
* server A is CollabNet's server, holding SourceCast source
- access via https using your corporate password
* server B is svn.collab.net, holding Subversion source
- access via http using your svn.c.n password
* your working copy uses svn:externals to aggregate these two
Now, you go to do a commit and enter your user/pass for CollabNet's servers.
It is nicely protected via https, all is good. Then svn goes to commit
against svn.collab.net and it sends your corporate password over the public
Internet in the clear via http:.
See the problem? :-)
On an unrelated note, I also realized that you're allocating the credential
values in the auth baton's pool. That's no good either... that pool will
just grow without bound. The caller should continue to pass a pool for the
result value. Remember: internal pools are usually bad...
Cheers,
-g
--
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
Re: auth cache (was: svn commit: rev 5006 - in trunk/subversion: include libsvn_ra_dav libsvn_auth)
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> * 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...
Sorry, I'm confused. I think I'm dreadfully ignorant of security
issues. Why is this a problem?
The whole libsvn_auth design is based around the idea of repeatedly
generating creds. Generate creds; if they fail to authenticate,
try again; repeat until out of options.
Why does it matter that we send A's password to B? Big deal, the
creds don't work, so we start asking providers to generate them
instead. We're just adding an extra 'attempt' before hitting the
real providers, which may or may not work.
Or is the real issue here that we need to treat B as a hostile server,
and assume that it will remember any bad creds we ever send it? Is
that what I'm missing?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
auth cache (was: svn commit: rev 5006 - in trunk/subversion: include libsvn_ra_dav libsvn_auth)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 21, 2003 at 10:10:04PM -0600, cmpilato@collab.net wrote:
> Greg Stein <gs...@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