Philipp Marek wrote:
On Thursday 07 August 2008 Gunnar Thielebein wrote:
When using ssl-client authentication a password is not needed anymore at
least in our setup.
So I hacked this dirty patch which introduces a new option "password"
for setting a global (blank) password.
I works for me but I don't know if there are better ways of implementing
this.
You just wrote "a password is not needed anymore"? Why make one configureable?
Hi Phil,
I think I need to explain our scenario a little bit.
On one hand we use ssl-keybased authorisation for servers. This keeps us
from typing password in authentication process because of security.
On the other hand we need the username of the commiter to track changes
to the config. This wont be the case without using htaccess.
So we use anonymous access on server so that only a (real) username is
needed on clientside, no matching password.
Without the local ~/.subversion directory and performing "svn ls" fsvs
also asks for the password when doing a commit.
So i wasn't able to nail this issue down and I created the patch.
Perhaps another configuration "anonymous_access" would make more sense
but I don't know what to use as an argument to this function instead of
a string or NULL:
racallback.c#58:
opt__get_int(OPT__PASSWD) ?
opt__get_string(OPT__PASSWD) : NULL, /*
Password */
If it would be possible to save the credentials in home ~/.subversion
(without svn client) this option would
not be neccessary at all.
And what exactly does not work?
saving the httpauth-credentials
But because I have defined /etc/subversion as configuration path
(because ssl configuration should be in global scope) imo it isn't saved
yet.
I am interested what you think about this!
Well, seems ok so far - but there's this discussion about storing plain-text
passwords (like svn had a few times in the past) ...
Do I understand you correctly: Because /etc/ is the configuration path, the
password (that gets asked on checkout) is not stored in the files; but for
commit you use client certificates, so you don't need it anyway?
I'm a bit confused.
this was only assumption from my side.
I don't know if the behaviour changes when using ~/.subversion should I
test this?
Regards,
Phil
Best Wishes,
Gunnar
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
