On 03/20/2013 05:34 PM, Bert Huijben wrote: >> -----Original Message----- >> From: C. Michael Pilato [mailto:cmpil...@collab.net] >> Sent: woensdag 20 maart 2013 12:14 >> To: Bert Huijben >> Cc: Subversion Development >> Subject: New svn_auth_cleanup_walk() API. >> >> Bert, >> >> I have some questions about the new svn_auth_cleanup_walk() API you >> introduced in trunk. >> >> First, I see that the function drives a new cleanup callback function. That >> functions has parameters named 'cred_kind' and 'provider'. Now, my >> understanding is that 'cred_kind' is one of the credential type string >> identifies we use through the svn_auth code -- "svn.simple", >> "svn.username", >> etc. 'provider', I think, is going to name one of our third-party storage >> providers -- "gnome_keyring", "keychain", "windows", etc. >> >> When I read the implementation of this function -- and specifically the >> svn_auth__simple_cleanup_walk() function that really does all the work -- I >> see this cleanup callback called with a cred_kind argument but with the >> provider always as SVN_AUTH_CRED_SIMPLE -- which is a cred_kind value! > > I think our file provider uses the same name as the credential type. Not 100% > sure though. > (Should be easy to debug with the auth-tests.c file)
If this is true, I'd strongly like for us to consider changing this and
assigning a unique name ("plaintext") to that provider.
>> Another question: it appears that we disallow cleanup of creds when
>> 'no-auth-cache' is set. I should think that's one of the key times when a
>> user would *want* to clean out existing cached authn creds. But maybe I'm
>> missing something here.
>
> When there is no auth cache the auth baton doesn't contain the path to
> where the credentials are stored, so it will be kind of hard to delete
> them... We can't iterate over them if we don't have the location. We
> could only delete the last credentials stored in ram.
This is very surprising to me, since "no_auth_cache" isn't a status (as in,
"there is no auth cache") but is instead an operational requirement ("do not
cache any auth credentials"). Even with --no-auth-cache passed on the
command-line, Subversion is free to (and in fact, does) *read* from the cache.
$ svnadmin create repos
# Checkout, but don't store auth creds
$ svn co http://localhost/tests/repos wc --no-auth-cache
Authentication realm: <http://localhost:80> Subversion Repository
Password for 'cmpilato': ********
Checked out revision 0.
# Update, still don't store creds
$ svn up wc --no-auth-cache
Updating 'wc':
Authentication realm: <http://localhost:80> Subversion Repository
Password for 'cmpilato': ********
At revision 0.
# Update, but this time it's okay to store creds.
$ svn up wc
Updating 'wc':
Authentication realm: <http://localhost:80> Subversion Repository
Password for 'cmpilato': ********
At revision 0.
# Update again, but don't store creds. (Notice that we've *read*
# the cache though.)
$ svn up wc --no-auth-cache
Updating 'wc':
At revision 0.
$
--
C. Michael Pilato <cmpil...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
