On Wed, 30 Dec 1998, Paul Everitt wrote:

Magnus wrote:

...

It still would be nice to have a standard tool that worked with Zope (at least IMO.) I guess it would be possible to follow the route of pgp and have two versions etc... No?

I personally feel that if we have FTP covered, we can then focus on WebDAV. The WebDAV spec requires Digest Authentication. That answers But it may be so. The payload contains potentially authentication information for the webserver, right? Password changes, etc.

AND the RFC (Digest authentication) authors explicitly state that digest authentication is unsecure by any measurement but basic authentication. (Cite RFC 2069: section 3.6 Summary: By modern cryptographic standards Digest Authentication is weak. .... The bottom line is that *any* compliant implementation will be relatively weak by cryptographic standards, but *any* compliant implementation will be far superior to Basic Authentication. Cite end) digest authentication is vunerable (depending upon the implementation but in concept it is) to things like replaying, etc.

much of the problem, unless people really feel that encrypting the payload is as important as encrypting the authentication.

That naturally depends. But usually you would want to do this. For example in my case, authentication/security information are uploaded via POST/PUT to the webserver. Doing this without full encryption is plainly stupid IMHO. But then, looking at some of my friends, I have to stipulate that they like to being hacked and explaining the downtime to their clients, ... (The last clue for me was that the guy explicitly asked me how to enable root FTP logins, so he can upload data when being at a clients site, ... *shudder*)

Digest authentication has no export restriction. It is a standard with free implementations. SSH2, with its non-free license, is a big That's why I prefer HTTP over SSL ;) problem. WebDAV represents an extension of the Web object model in a way that Zope is uniquely positioned to exploit.

Still, there is no one approach that suits everyone, just as there is no one Python GUI. Since Zope is free and open source, I'm eagerly awaiting contributions that reflect people's unique requirements. As some one (I think it was Jeff) said to me, when I suggested to use Apache's py_mod to eliminate the fork/exec of pcgi, this would be like putting in a 500kg interpreter into a 50kg webserver to remove 10kg of fork/exec work.

The same applies here: I'm not sure if I want to wrestle with a 500kg Zope for a job that 10kg of python code & Bobo/DT solve quite well. (Actually publisher at the moment is 965 lines of code (24KB) after clean ups at the moment. But then I've got some idea's that will hopefully be implemented today :) )

...

And personally -- I usually sit at the machine where the webserver is located, so it would be very nice to be able to edit the document methods directly in emacs... (I guess it would be possible to make an emacs-lisp program that interacted with Zope, but it seems a bit unneccesary...)

Personally I think this is the *right* way to do it. I believe

*strongly* in objects and I feel that editing the data directly is a violation of encapsulation. *But*, Zope is a free, open system and others can do what they want, including discarding the object database (as both Andreas and Skip have done).

--Paul

Paul Everitt Digital Creations paul@digicool.com 540.371.6909

-- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.