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

Re: Options for how ra_svn client authenticates

From: Glenn A. Thompson <gthompson_at_cdr.net>
Date: 2003-10-17 07:28:25 CEST


>THE SOLUTIONS (from most likely to least likely):
> (1) If the repository has a password database,
Could you elaborate on this. I don't like the idea of a password
database being in the repository.
Unless it resides behind some sort of api that allows alternate

>the server offers
> both CRAM-MD5 and ANONYMOUS mechanisms, but the client always
> picks CRAM-MD5 and prompts the user for a password. If you want
> to offer some anonymous operations, you have an anonymous user
> with a published password, or maybe you run a server on a
> different port which is configured not to have a password
> database. (That second option might be harder to make possible
> if the user database is per-repository, but that's a separate
> topic.)
> This is probably okay because:
> - It's what CVS offers.
> - It's how mod_authz_svn currently works, due to a limiation
> in Apache 2.0.
I read through the IRC text. I think I understand the Apache
limitation. However, I'm not in the habit of inviting a stranger into my
house and then asking his name when I discover he's a thief. I think
it's reasonable to know a strangers name. Some of the situations
impacted by the limitation can be handled by using additional location
tags that don't require authentication.

> VARIATION: We could add a --anonymous client flag which forces
> the client to attempt the operation anonymously and fail if
> that's not allowed. It would work by forcing all the
> interesting authentication token providers to fail. Garrett
> wonders whether it's worth adding such an option, if it wouldn't
> get much use. (Note that the option also applies to ra_dav,
> although it's less exciting there since it would just mean "fail
> out if authentication is required".)
Please don't:-)

> (2) Make ra_svn more like ra_dav, where at any point during an
> operation, the server can say "hold on there, I'm going to need
> to see some ID," at which point the client presents credentials.
Did I mention my wife locks the door during the day when she's home
alone. I think she might get upset if she were to suddenly discover
someone in her living room. But, if she knows you ... well sit down;
would you like something to eat. How 'bout a cookie.

My point is, if you know there is the potential that authz violations
may occur get some credentials up front. If you are allowing anonymous
access and a authz violation occurs. Shoot and ask no questions. See
ya punk.

So, I prefer having two ports one folks connect to if there are
potential authz restrictions and a second for anonymous access. Yes I
realize that if authz restrictions exist that limit read access for
certain paths this doesn't work. But I would make the argument that a
repository which limits read access should never allow anonymous access.

Just my 2 cents


PS if anyone asks, I've made no posts to this list for weeks. Nope, we
haven't heard hide nor hair from him;-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 17 07:34:04 2003

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

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