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

Re: Awful first cut of ra_svn password authentication

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-10-17 02:56:11 CEST

Greg Hudson <ghudson@MIT.EDU> writes:

> * I am a bit lost on how to integrate this on the client side. Our
> current auth framework is based on an HTTP model where you try all
> operations anonymously and retry them with authentication (in a
> specific realm) if the server asks for it. (Corollary: if a
> server allows anonymous commits, but you want to authenticate
> anyway to get your username recorded, you can't do that.) I
> didn't design the ra_svn protocol and implementation with the HTTP
> model in mind, so I'm a little stuck. The client integration in
> this patch is inflexible and broken; it's just enough to let me
> exercise the code.

Mmm, client-pushing-creds vs. server-pulling-creds. Interesting.

Kudos on moving forward on this idea!

My comments are below. Sorry for the delay, I've been real busy this week.

> * On the server, the natural place to put the password database is
> inside the repository. But you can't, because authentication
> happens before a repository is selected.

I really like the idea of placing an svnserve password file into a
repository. I have a couple of ideas about how to proceed...

One answer: it can't be that hard to make svnserve do a credential
"pull", can it? It can issue a challenge at the appropriate point in
the dialogue, rather than doing it at connection time. Make 'svnserve
-d' accept an initial unauthenticated connection. When the client
tries to RA->open() a specific repository, check the repository for
any password file: if present, issue an auth challenge. Or maybe I'm
just completely ignorant of CRAM standards...? Enlighten me.

Another variant which you might like better: have 'svnserve' accept
credentials with the initial connection, but cache them in memory.
When RA->open() is called, use them against the specific repository's
password file. If no password file is present, you can still use the
username as the author of a newly committed revision. Easier than
using the --believe-username switch.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 17 02:58:36 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.