I need the DAV protocol for more than just editing filesystem files in the
real web tree.
My version (Dave's Advanced Vaporware or DAV) will have multiple handlers
(the first version will just have the filesystem handler) and the files will
be at
/dav/${handler}${url} i.e. /dav/davfile/users/grax/index.htm or
/dav/davcontentmanagement/articles/whats_a_meadow_for.html
This way the GET command returns editable source and not the modified final
version the web site visitors will see. If I can figure out the "source"
feature of the DAV spec, and if clients actually implement it, then I think
this method might even work practically invisibly.
On Tuesday 09 April 2002 01:42 pm, you wrote:
> +---------- On Apr 9, Zoran Vasiljevic said:
> > If I'm not mistaken (correct me if I'm wrong, please),
> > but, if I do not load the ns_perm module then:
> >
> > - I do not get the "allowuser" functionality (or is it "ns_perm
> > allowuser"?) - I lose all other user's hostname (ip/domain) checking
> > - Ns_AuthorizeRequest always grants access if I do not register
> > my own authorization callback function
> >
> > If above holds true, then this can be used as a starting point
> > when developing DAV, indeed.
>
> Yes, it holds true.
>
> Personally, I'd not be inclined to use a single server for both DAV and
> normal web serving. By separating the services into different processes,
> you can run the normal web server as a uid that only has read access to
> the files, and the DAV server as a uid that has write access. Then you
> can restrict the DAV server to only allow SSL connections (and not even
> load nssock), and use different firewall rules for the two servers.
>
> In fact, this is how I set up some sites I host: I use nsd as the web
> server with read-only access to the files, and Apache/mod_dav to allow a
> select few to update the content. I don't even allow direct connections
> to the DAV server over the Internet - I require the remote users to
> connect through an SSH tunnel.
>
> > But, I'm afraid that people would really need both (basic and digest
> > and/or some other scheme in the future) at the same time when it comes
> > to deployment. That's why a hook in the Ns_AuthorizeRequest allowing
> > other schemes would be a good thing. Hopefully this thread will serve
> > as a kick for somebody to consider doing a proper integration work in
> > the core server.
>
> It as already possible to use both at the same time (for different
> URLs), as I described. Just make nsperm allow "" to access any URL that
> is handled by the Digest filter.
>
> I agree that the authorization hooks could be improved. However, it's
> possible to use Digest authorization today, without writing or changing
> any C code. You just have to write a Tcl filter.
