Two general questions have been cropping up more and more lately (on-list
and off) regarding ViewVC:
* What's up with the path-based authorization code these days -- is
it finally finished?
* When is ViewVC 1.1 coming out?
The answer to the latter is largely tied to the resolution of the first.
And the answer to the first is, "Quite honestly, I'm stuck."
The trunk holds the work done so far for the path-based authorization
support. It mostly works, too, I'm happy to say. But there are a couple of
issues that concern me.
First, I haven't been able to decide how to deal with Subversion revision
properties (log message, author, date). Subversion's own policy around the
display of these things to a given user is built around path-based authz,
and calculated for a given revision by checking the readability of the paths
changed in that revision. For example, if the authz rules for the
repository say that I'm allowed to see changes everywhere except in a
"/private" directory then:
* I can see all the revision properties, and all paths in the
changed-paths list, for revisions in which nothing in or under
/private was changed. [full access]
* For revisions in which only paths in and under /private were
changed, I can't see any revision properties or items in the
changed-paths list. [no access]
* For revisions where some paths under /private were changed and
some paths *not* under /private were changed, I can see the
date and author properties, and only the non-/private paths
in the changed-paths list. [partial access]
Because I currently have the vcauth code (the authorization layer) laid atop
the vclib stuff (the generic version control abstraction), I'm in a weird
spot trying to either make these types of determinations only for one
version control system, or apply them to other systems which perhaps don't
natively have such rules. CVS doesn't even have global revisions with
various changed paths associated with them, so what does it mean to ask
about the viewability of a CVS log message?
The second ... discomfort I have today is that I think I might have keyed
things all wrong. I was aiming for a modular system which lets you drop a
Python module into place that implements a given class and *poof* you've got
an authz plugin. I still like that kind of modularity, but I'm concerned my
layers might be misordered.
Today, you can write one authz plugin (or use one of the provided ones) and
it can apply to both CVS and Subversion backends. This is really neat in
some ways -- it means you can use Subversion's trivial authz file format to
add access control to CVS repositories, too. That's cool because CVS
doesn't really have its own access control mechanism aside from file
permissions, which don't work so well in a CGI environment where the ViewVC
script always runs as the same user regardless of who is sitting at the
browser on the other end of the wire. But what about CVSNT, which has its
own ACL subsystem? Wouldn't someone using that for their CVSNT installation
presumably want to also use it for their ViewVC views? And how then would
that make sense as a VC-agnostic authz plugin?
Finally, of interest (and issue) here is ViewVC configurability. Right now,
you can define per-authz configurations, per-root configurations, and
per-vhost configurations, and to be honest, I can't recall at the moment in
which order they get handled. Part of me thinks that what's provided is too
complex already. Part of me thinks that what's provided isn't enough
because there's not also per-VCS configuration ("use 'svnauthz' for all
Subversion roots, use 'forbidden' for all CVS roots", e.g.).
Any and all thoughts and suggestions on how to untangle this mess are very
much appreciated -- I'm not opposed to ripping out the authz stuff and
starting afresh if that's what's required.
And I'm *terribly* sorry for not having reached out for help much earlier
than this. ViewVC users deserve better than that.
-- C-Mike
PS: There are other things that I think would be nice to get into ViewVC
1.1, such as unification of the markup and annotate views. But
maybe we should just get the thing out the door ASAP with working
authz stuff. At some point I'd like to do a deep performance-
improvement dive, too. I've got some ideas on that already that
I'm pretty excited about.
--
C. Michael Pilato <cmpilato@xxxxxxxxxx>
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
|
