username/password caching

[Philip Martin <ph...@codematters.co.uk>]

Hello

What's the state of libsvn_auth, is it supposed to work?  Back in the
old days I set store-password=no to avoid having my password cached.
When I committed I was only asked to enter my password, the username
was obtained from the cached value in the working copy.

That hasn't worked for some time.  When I commit I have to enter both
my username and my password, even though my username is present in a
file in the working copy.  Is this change deliberate?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: username/password caching

[Ben Collins-Sussman <su...@collab.net>]

Philip Martin <ph...@codematters.co.uk> writes:

> What's the state of libsvn_auth, is it supposed to work?

Technically, it's "done".  We're ready for David Waite's client-side
certs provider now.  :-)

> Back in the old days I set store-password=no to avoid having my
> password cached.  When I committed I was only asked to enter my
> password, the username was obtained from the cached value in the
> working copy.
> 
> That hasn't worked for some time.  When I commit I have to enter both
> my username and my password, even though my username is present in a
> file in the working copy.  Is this change deliberate?

Yes, it's my fault, I apologize.  I noticed that we had a
--no-auth-cache commandline switch, and also had a 'store-password'
config file variable.  I said to myself, "bah, these two things should
just map to the same concept.  The only difference is that one is
temporary, and one is permanent."

I guess I was too eager to oversimplify.  I didn't realize anyone out
there actually wanted something in between "cache nothing" and "cache
everything".  

But cmpilato has already proposed a solution to get the halfway-state
back again.  :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: username/password caching

[cm...@collab.net]

Ben Collins-Sussman <su...@collab.net> writes:

> cmpilato@collab.net writes:
> 
> > Then I thought, what if each provider's "save" function accepted a
> > flag that dictated the amount of data to save:
> > 
> >    'none' - store no creds (but the system would call the function
> >      anyway in case the provider needs to do some kind of cleanup or
> >      admin task).
> > 
> >    'username' - store a username only.
> > 
> >    'all' - store all the creds.
> > 
> > Then, we would change the config option to "auth-cache-type" (and the
> > valid values would be 'none', 'username', or 'all', defaulting to
> > 'username') and then change the command-line argument to
> > "--auth-cache-type" with the same three valid values.
> 
> +1 on this idea, provided it's not a flag to every single save_creds()
> implementation.  Instead, it should be a simple runtime parameter in
> the auth_baton hash.  It can either be specific to the wc provider, or
> global to all providers that might want to care.

Ah yes, the hash.  Forgot about that.  +1!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: username/password caching

[Ben Collins-Sussman <su...@collab.net>]

cmpilato@collab.net writes:

> Then I thought, what if each provider's "save" function accepted a
> flag that dictated the amount of data to save:
> 
>    'none' - store no creds (but the system would call the function
>      anyway in case the provider needs to do some kind of cleanup or
>      admin task).
> 
>    'username' - store a username only.
> 
>    'all' - store all the creds.
> 
> Then, we would change the config option to "auth-cache-type" (and the
> valid values would be 'none', 'username', or 'all', defaulting to
> 'username') and then change the command-line argument to
> "--auth-cache-type" with the same three valid values.

+1 on this idea, provided it's not a flag to every single save_creds()
implementation.  Instead, it should be a simple runtime parameter in
the auth_baton hash.  It can either be specific to the wc provider, or
global to all providers that might want to care.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: username/password caching

[cm...@collab.net]

Philip Martin <ph...@codematters.co.uk> writes:

> Hello
> 
> What's the state of libsvn_auth, is it supposed to work?  Back in the
> old days I set store-password=no to avoid having my password cached.
> When I committed I was only asked to enter my password, the username
> was obtained from the cached value in the working copy.
> 
> That hasn't worked for some time.  When I commit I have to enter both
> my username and my password, even though my username is present in a
> file in the working copy.  Is this change deliberate?

For a period of time during the auth system transition, none of the
special config or command-line options were working.  This should be
fixed now -- at least, that's what's intended.

---

Ben: remember how you and I were thinking it was ridiculous that the
config option "store-password" was only about storing the password,
yet the --no-auth-cache command-line option was for not storing *any*
creds, and we talked about making them do the same thing (either store
all or store none)?

I've been thinking about that some more.

On the one hand, giving the user only the options of "store
everything" or "store nothing" means they might have to provide both a
username and password for each committing command.  That could get
annoying.  

Then I thought, what if each provider's "save" function accepted a
flag that dictated the amount of data to save:

   'none' - store no creds (but the system would call the function
     anyway in case the provider needs to do some kind of cleanup or
     admin task).

   'username' - store a username only.

   'all' - store all the creds.

Then, we would change the config option to "auth-cache-type" (and the
valid values would be 'none', 'username', or 'all', defaulting to
'username') and then change the command-line argument to
"--auth-cache-type" with the same three valid values.

This would let the super-paranoid choose to be annoyed by requests for
usernames (where getuid() didn't pan out, of course), would let the
average joe at least cache the username, and then would allow the
carefree to enable full caching (also called "stop pestering me
mode").

Thotz?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org