Assume, in the near future, that ra_svn supports password
authentication and mod_authz_svn-style path-based authorization.
THE PROBLEM: Let's say we have a server which wants to support some
operations anonymously and some operations when authenticated. This
could be "anonymous reads, authenticated commits" or, in the more
exotic case, "anonymous reads and commits, except to part of the
repository where we only allow authenticated commits."
At connection time, svnserve has no idea what operation we're about to
perform. For that matter, neither does ra_svn_open() on the client.
So we do not know whether the user needs to password-authenticate or
not. However, unlike ra_dav (but like many stateful protocols),
ra_svn requires authentication to happen at ra_lib->open() time, and
not later on.
THE SOLUTIONS (from most likely to least likely):
(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.
This is bothersome because:
- It imposes a particular authentication policy on all
clients, not just the ones we write. Our libraries simply
wouldn't le the client decide whether or how to
authenticate.
- Eventually Apache's limitation will be removed and ra_dav
will become more flexible than ra_svn for this use case.
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".)
(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.
This is tough because ra_svn is a stateless protocol. However,
we can cut down on the toughness with the following
observations:
- We don't need to be able to ask for authorization in the
middle of a commit; it's good enough to be able to ask at
the end.
- For a checkout, we know at the beginning what paths are
going to be accessed, so again, we don't have to be able to
ask in the middle of an edit.
- For an update, there might be a tricky case where the
success of an update depends on the report. (If I can
access src but not src/veryprivate, can I do a non-recursive
checkout of src and then update that?) But we should at
least be able to determine the answer after getting the
report and before starting the edit. So again, no need to
ask in the middle of an edit or report.
However, in addition to being hard, this is a little suboptimal
because:
- In some cases, authentication might be requested after some
number of notifications have been displayed. That idea
didn't seem to bother Ben, but it seems weird to me.
- It doesn't let you attach your name to commits if the commit
can be performed anonymously. (ra_dav has this limitation,
and it doesn't seem to bother many people, but it is a
limitation.)
(3) Add an option for the client to specify how it wants to
authenticate; something like "--auth={password,anonymous}" for
now with other possibilities added later.
This is maybe worth doing because:
- It provides the most flexibility for clients.
- That flexibility might (or might not) become more important
when we have more mechanisms available.
- It's similar to how many protocols work, like authenticated
SMTP.
This is bad because:
- It requires changing the auth framework to support
client-push in addition to server-pull.
- It makes the user model rather different between ra_svn and
ra_dav.
- Most users don't know different authentication options from
their butt, and it's much more usable to ask "you need to
give your password now, what is it?" than to make the user
say ahead of time, "I want to give a password."
(4) The server presents ANONYMOUS and CRAM-MD5 as in (1), but the
client first tries with ANONYMOUS. If the operation fails with
an authorization error, the client tries again with CRAM-MD5.
This would kind of suck because:
- By the time the operation fails, we might have already
presented some notifications to the client. It would look
very amateurish (and confusing) to display those twice.
- It's not very efficient for a big operation (although most
big operations would fail pretty early on).
- If the user has saved credentials, it would be nice to skip
the "try anonymously" step, and we'd have to extend the auth
framework to allow that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 17 05:03:44 2003