Re: New svn_auth_cleanup_walk() API.

On 03/20/2013 05:34 PM, Bert Huijben wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato_at_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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development