You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2003/02/20 14:50:08 UTC
authentication cache
Hi,
if I call e.g. svn_client_ls() on a password
protected repository then Subversion asks
(if used) via prompting providers for the
authentication. But if I do another svn_client_ls()
right after that (on a directory below the last)
with the same ctx-object then Subversion
asks again for authentication.
Are there plans to cache those username/passwords
during one session? This most likely won't affect
the command line client but some GUI clients like
mine...
Stefan
Re: authentication cache
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"SteveKing" <st...@gmx.ch> writes:
> > we cache an authentication baton now, i don't know what needs to be done
> > to the baton to make it cache the password, but i thought it would do
> > that automatically...
>
> It seems that information gets somehow lost. I haven't found where exactly
> this is (yet) but I can definitely say that it's not persistent.
Hey, if you can trace it down, that would be great. As far as I know,
the stuff in those context batons is supposed to be persistent, that's
why we have them in the first place :-)...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by SteveKing <st...@gmx.ch>.
> Karl Fogel wrote:
>
> >"SteveKing" <st...@gmx.ch> writes:
> >
> >
> >>if I call e.g. svn_client_ls() on a password
> >>protected repository then Subversion asks
> >>(if used) via prompting providers for the
> >>authentication. But if I do another svn_client_ls()
> >>right after that (on a directory below the last)
> >>with the same ctx-object then Subversion
> >>asks again for authentication.
> >>
> >>Are there plans to cache those username/passwords
> >>during one session? This most likely won't affect
> >>the command line client but some GUI clients like
> >>mine...
> >>
> >>
> >
> >I thought we were planning to cache them in there. Garrett, does that
> >match your understanding?
> >
>
> we cache an authentication baton now, i don't know what needs to be done
> to the baton to make it cache the password, but i thought it would do
> that automatically...
It seems that information gets somehow lost. I haven't found where exactly
this is (yet) but I can definitely say that it's not persistent.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > I think the solution here is simple: the auth_baton can cache the last
> > returned set of credentials (of each type). Then we change first_creds()
> > to always return the cache, if available. Pretty easy.
>
> Instead, the GUI can create an in-memory caching provider.
I thought of doing that, but providers have no way of communicating
with one another. If the third provider produces creds, there's no
way the 'caching' provider can know about them. The runtime-parameter
hash won't work as a means of communication, because then every
provider in the world needs to remember to put the creds in there.
> I don't think that it should be built into the auth system,
> especially given that any particular set of credentials returned
> could be arbitrarily keyed by parameters that were set at runtime.
Why is that a problem? The worst thing that can happen is that the
cache is useless, so the first provider kicks in on the next retry.
If the cached creds are based on runtime params that changed between
different RA sessions, then the cache *should* fail, and the user
should be reprompted anyway.
> 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.
I already implemented the simple solution -- is it bad?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Feb 20, 2003 at 12:51:37PM -0800, Ben Collins-Sussman wrote:
>...
> Heh, this isn't a bug, it's just a libsvn_auth design oversight.
Nope. See below.
> Our main commandline client:
>
> creates a ctx object
> creates an auth_baton with various providers
> runs a single subcommand
> calls first_creds, next_creds, next_creds ...
> exits
>
> There's simply no caching design here at all, which would be needed by
> long-running GUI clients.
>
> What's happening with a GUI client is this:
>
> creates a ctx object
> creates an auth_baton with various providers
> run many subcommands
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> exits
>
> I think the solution here is simple: the auth_baton can cache the last
> returned set of credentials (of each type). Then we change first_creds()
> to always return the cache, if available. Pretty easy.
Instead, the GUI can create an in-memory caching provider. I don't think
that it should be built into the auth system, especially given that any
particular set of credentials returned could be arbitrarily keyed by
parameters that were set at runtime.
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>"
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: authentication cache
Posted by SteveKing <st...@gmx.ch>.
> > My test case is to run 'svn ls URL1 URL2' on a read-protected
> > repository. At the moment, svn will prompt you twice, because it's
> > two seperate calls to svn_client_ls(). With my patch, the second
> > prompt doesn't happen anymore. The credentials are being cached in
> > the auth_baton between calls to client functions.
>
> OK Steve, auth credentials are now being cached between successive
> calls to svn_client_* functions. Just update your svn source to
> r5006 or later. Let me know if it works for TortoiseSVN!
Updated, compiled (man I need a faster computer, took me 20 minutes
to compile the whole thing!) and tested: works like a charm!
Thanks for the work!
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Ben Collins-Sussman <su...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> My test case is to run 'svn ls URL1 URL2' on a read-protected
> repository. At the moment, svn will prompt you twice, because it's
> two seperate calls to svn_client_ls(). With my patch, the second
> prompt doesn't happen anymore. The credentials are being cached in
> the auth_baton between calls to client functions.
OK Steve, auth credentials are now being cached between successive
calls to svn_client_* functions. Just update your svn source to
r5006 or later. Let me know if it works for TortoiseSVN!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Ben Collins-Sussman <su...@collab.net>.
"SteveKing" <st...@gmx.ch> writes:
> > creates a ctx object
> > creates an auth_baton with various providers
> > run many subcommands
> > calls first_creds, next_creds, next_creds ...
> > calls first_creds, next_creds, next_creds ...
> > calls first_creds, next_creds, next_creds ...
> > exits
> >
> > I think the solution here is simple: the auth_baton can cache the last
> > returned set of credentials (of each type). Then we change first_creds()
> > to always return the cache, if available. Pretty easy.
>
> Since I'm not very familiar with that code would you do it please?
Finished. I'm testing my patch now.
My test case is to run 'svn ls URL1 URL2' on a read-protected
repository. At the moment, svn will prompt you twice, because it's
two seperate calls to svn_client_ls(). With my patch, the second
prompt doesn't happen anymore. The credentials are being cached in
the auth_baton between calls to client functions.
I'll commit as soon as I'm convinced I didn't break anything, probably
late tonight. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by SteveKing <st...@gmx.ch>.
> Heh, this isn't a bug, it's just a libsvn_auth design oversight.
I never said that :)
> Our main commandline client:
>
> creates a ctx object
> creates an auth_baton with various providers
> runs a single subcommand
> calls first_creds, next_creds, next_creds ...
> exits
As I said: it won't affect the command line client. That's why
I asked if I'd have to write my own provider for that or
if it will get into subversion itself.
> There's simply no caching design here at all, which would be needed by
> long-running GUI clients.
>
> What's happening with a GUI client is this:
>
> creates a ctx object
> creates an auth_baton with various providers
> run many subcommands
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> calls first_creds, next_creds, next_creds ...
> exits
>
> I think the solution here is simple: the auth_baton can cache the last
> returned set of credentials (of each type). Then we change first_creds()
> to always return the cache, if available. Pretty easy.
Since I'm not very familiar with that code would you do it please?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Ben Collins-Sussman <su...@collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Garrett Rooney <ro...@electricjellyfish.net> writes:
> > >I thought we were planning to cache them in there. Garrett, does that
> > >match your understanding?
> >
> > we cache an authentication baton now, i don't know what needs to be
> > done to the baton to make it cache the password, but i thought it
> > would do that automatically...
>
> Hmmm. That sounds like there's a bug then, no?
>
> Ben will know the answer to this off the top of his head :-). He was
> up till three last night, so he just hasn't seen this mail yet.
Heh, this isn't a bug, it's just a libsvn_auth design oversight.
Our main commandline client:
creates a ctx object
creates an auth_baton with various providers
runs a single subcommand
calls first_creds, next_creds, next_creds ...
exits
There's simply no caching design here at all, which would be needed by
long-running GUI clients.
What's happening with a GUI client is this:
creates a ctx object
creates an auth_baton with various providers
run many subcommands
calls first_creds, next_creds, next_creds ...
calls first_creds, next_creds, next_creds ...
calls first_creds, next_creds, next_creds ...
exits
I think the solution here is simple: the auth_baton can cache the last
returned set of credentials (of each type). Then we change first_creds()
to always return the cache, if available. Pretty easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> >I thought we were planning to cache them in there. Garrett, does that
> >match your understanding?
>
> we cache an authentication baton now, i don't know what needs to be
> done to the baton to make it cache the password, but i thought it
> would do that automatically...
Hmmm. That sounds like there's a bug then, no?
Ben will know the answer to this off the top of his head :-). He was
up till three last night, so he just hasn't seen this mail yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Karl Fogel wrote:
>"SteveKing" <st...@gmx.ch> writes:
>
>
>>if I call e.g. svn_client_ls() on a password
>>protected repository then Subversion asks
>>(if used) via prompting providers for the
>>authentication. But if I do another svn_client_ls()
>>right after that (on a directory below the last)
>>with the same ctx-object then Subversion
>>asks again for authentication.
>>
>>Are there plans to cache those username/passwords
>>during one session? This most likely won't affect
>>the command line client but some GUI clients like
>>mine...
>>
>>
>
>I thought we were planning to cache them in there. Garrett, does that
>match your understanding?
>
we cache an authentication baton now, i don't know what needs to be done
to the baton to make it cache the password, but i thought it would do
that automatically...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: authentication cache
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
"SteveKing" <st...@gmx.ch> writes:
> if I call e.g. svn_client_ls() on a password
> protected repository then Subversion asks
> (if used) via prompting providers for the
> authentication. But if I do another svn_client_ls()
> right after that (on a directory below the last)
> with the same ctx-object then Subversion
> asks again for authentication.
>
> Are there plans to cache those username/passwords
> during one session? This most likely won't affect
> the command line client but some GUI clients like
> mine...
I thought we were planning to cache them in there. Garrett, does that
match your understanding?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org