[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: What is the easiest way to "preauthenticate" users?

From: Kalin KOZHUHAROV <kalin_at_thinrope.net>
Date: 2005-11-02 14:42:00 CET

Sorry for the bit long delay :-|

Doyle, Patrick wrote:
>>>>I would like to figure out the easiest way for users to authenticate
>>>>themselves with my Subversion server the first time
>>>>(recognizing that, subsequent to that first time, the authentication
>>>>data will have been cached).
>>So, you want to have your user never to be asked about
> I don't mind being asked once -- what I am looking for is something similar
> in concept to the the "cvs login" command of the olden days.
>>In other words, you want their credentials cached?
> Yes
>>What protocol are you using? (HTTP/svn/svn+ssh)
> svn
You "hit the target" :-| I have never used the svn protocol...
Is svn+ssh a problem to use? Or too slow?
I use about 60% svn+ssh and 40% https in my daily work.

>>There is always a solution, but it is protocol dependent. And
>>probably (client) OS dependent.
>>What OS are your clients?
> Windows, Linux
>>We are talking about the built-in CLI, right? Actually it
>>should not matter.
> Yes, I am talking about the built-in CLI, and I agree, it shouldn't matter
>>When asking on any ML, provide enough information about your
> I suppose I thought my question was of such a generic nature that the
> environment didn't matter, but I'll fill in the blanks, just in case.

Well, even if it may be, the gurus tend to ignore one-line-questions, out of business and the
thought that you didn't RTFM enough.
It shows you are serious and have considered some options.
And it always helps subsequent discussions.

Below is a very good description of the problem!

>>0. Environment description (OS, product version, ...)
> Windows and Linux based environments, running Subversion release 1.2.3.
>>1. What you wanted to achieve?
> Ultimately, what I would like to achieve is something similar to the "cvs
> login" command to access a remote repository using the "svn" protocl,
> recognizing and understanding that the Subversion notion of having the
> server request credentials only when needed is substantially different than
> the traditional CVS notion.
>>2. What you did?
> What I've done is to modify a property on a directory and commit that change
> in order to prompt the server to request credentials from me. I have my
> environment set up so that those credentials are cached so that the next
> time the server requires credentials, it obtains them silently from the
> cache.
>>3. What happened?
> The server prompted me for my password. I gave my password. The client
> cached it. The next time the server needed a password, the client supplied
> it from the cache without pestering me for it.
>>4. What was supposed to happen?
> Exactly what I described.
> I was just wondering if there were an easier mechanism than changing
> something in the repository simply to force that first exchange of
> credentials.

> Ryan Schmidt suggested that I could create the credendials file myself on
> the client side without ever pestering the server. That's a clever idea,
> and I doubt I would have come up with it myself. That's why I asked the
> question of the list.
Yes, I would suggest having a look at the source (haven't bothered with that part yet, but the code
is quite clear and easy to comprehend, AFAIR).

And if you do NOT have anonymous read permissions (you said you need "initial write permission" in
your first mail, but that does not contradict) on the repository, you can try a command that does
not change the repository (say `svn cat $URL >/dev/null`).

Hope that helps,

|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 2 05:42:06 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.