> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> Sent: Friday, January 31, 2003 9:53 AM
> "Sander Striker" <striker@apache.org> writes:
>
> > > More issue #724 - Some fixes, and now only try to save using the
> > > provider that supplied the creds.
> >
> > Huh? I really don't get this. A simple prompting provider won't
> > be able to save creds, so if a passwd is not in a cache it has no
> > chance of ever getting in? My take on this was try the provider
> > you got the creds from first, if that fails cycle over all others.
>
> Our simple prompting provider can, because it uses the same
> auth-storing function that the WC-cache-reading provider uses.
Ewww. This seems to defeat the whole purpose of the pluggable
provider API. Guess what happens if I want to use, say, an
svn-agent provider and a prompting provider? Now I have to either
reimplement prompting in the svn-agent provider, or, implement
a seperate prompting provider (can't reuse the svn prompting
provider since it will write my creds to disk(!)).
> > This can be done in the phase where we register the providers. If
> > --no-auth-cache is present, simply not register the provider that
> > gets/sets the user/pass in the working copy. And do register it
> > if store-password is present.
>
> I think WC auth-reading provider should be registered even if
> 'store-password' is "no".
Then just split the wc auth provider in a read and write provider.
Only register the write if you are allowed to cache on disk in the
wc.
> Just because the user no longer wants us to
> store his password doesn't mean it isn't already in the cache. :-)
True.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 31 10:06:07 2003