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