httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@liege.ICS.UCI.EDU>
Subject Re: Thoughts on authoring support...
Date Thu, 13 Jun 1996 00:31:51 GMT
A few thoughts.  First, I'm really glad you are looking into this,
since I think it is the next BIG feature worth supporting, and is
something I'll need to look into when I finally get around to doing
that dissertation thingy.

The W3C just started a working group on distributed authoring support;
I'd be more than happy to get you on that mailing list if you want.

Regarding the approach, I think it is important not to tie the server's
PUT capability so close to the filesystem.  What I would expect is a
layered security check, such as

    a) check that PUT is allowed for the requester (possibly authenticated)
       on the requested URL, and also any limits like max-size or type;

    b) check that the storage subsystem is PUT-writable by the webserver
       for that area of storage.

The first check needs to be independent of the filesystem to the same
extent that our existing access control is (preferably more so, but that
might require revamping access control entirely).  The second check
needs to be storage-system dependent, but should at least have an
abstract interface so that we can swap the filesystem with a DB or
a version control manager without losing PUT capability.

>    5) Unauthenticated PUTs should be flatly disallowed.  
> ...
> (5) is simple, and I hope, self-justifying; mod_auth_anon provides
> some kind of escape hatch for anyone foolish enough to *want* to allow
> any fool in the world to scribble all over their space.

I disagree here -- obviously that should be the default behavior, but
I see no reason to prevent people from setting up a truly anonymous
PUT-area for which they have no intention to ever check where the PUT
came from (in fact, for various legal reasons, do not want the ability
to find out where it came from).  Also, keep in mind that not all such
servers will be accessible to the "real net", and some sites could use
an internal server with no access control to build content for some
other, external server.

Most of the details you descibe are (b)-style checks.  My only useful
input there is to ask that the (a)-style checks don't get intermingled
with (b)-style mechanisms.


View raw message