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

Options for how ra_svn client authenticates

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-10-17 05:02:58 CEST

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

      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
        - 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
        - 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
        - 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

  (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
      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
        - 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

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.