Greg Hudson <ghudson@MIT.EDU> writes:
> (1) If the repository has a password database, 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.
> - It's easy to implement.
It's not quite what CVS offers, actually.
Since this may be relevant to both ra_dav (which has anonymous access
problems because of Apache) and ra_svn, here's some history:
In the bad old days, CVS servers required authentication even for the
anonymous, read-only user. The user had to do two steps the first
time they checked out a new project:
$ cvs -d :pserver:guest@cvs.foo.bar:/repos login
Password: *****
$ cvs -d :pserver:guest@cvs.foo.bar:/repos checkout projname
...
$
Since both 'guest' and '*****' might be different for different sites,
you always had to read the instructions. (Sometimes it was "guest",
sometimes "anonymous", sometimes "anon", and so on.) Very annoying.
The first step in fixing this was to give the server a new syntax in
the CVSROOT/passwd file:
someuser:BxlnKMgVbRlIY
anonymous:
otheruser:J39YUyQc4HqrM
The empty password meant "Accept *any* password the client sends,
including, but not limited to, the empty string."
The second step -- which actually came two years later, but hey, this
*is* CVS -- was to change the client to automatically send the empty
string as password, if the specified username wasn't found the
client's local passwd database (~/.cvspass).
This reduced the necessary bit of information to just the username.
If you knew it was 'anonymous', you could simply run
$ cvs -d :pserver:anonymous@cvs.foo.bar:/repos checkout projname
...
$
without logging in first. Both client and server would know what to
do.
The third step never happened, at least not yet. I *think* the third
step is to have a convention for the anonymous read-only username.
Any site that supports anonymous read-only access would use this
convention. Then the information needed by the user would be reduced
to just repos/project:
$ cvs -d :pserver:@cvs.foo.bar:/repos checkout projname
...or some syntax like that.
I guess that example implies that the username would be the empty
string; maybe the client would actually substitute "anonymous" by
convention or something. Dunno, haven't really thought it through.
I offer this history for two reasons:
1. Perhaps some part of CVS's strategy may suggest ways we can at
least partly solve our various ra_dav and ra_svn authentication
and authorization problems.
2. Let's not claim that we're no worse than CVS. CVS is not as bad
as people think in this area (of course, it helps that the
username is built into the access string). It's true that most
sites that offer anonymous CVS access still document the login
step, because they're afraid that people might be running old
clients. But they probably don't have to worry anymore -- the
relevant client changes were made in late 1999.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 17 17:35:12 2003