On Mon, 18 Jun 2001 12:28:54 -0400, Shane Hathaway <shane@digicool.com> wrote:
1) Optional password encryption. Right now passwords are stored as clear text.
I dont understand the advantage of this scheme as applied to Zope. As long as basic authentication is used, a system administrator is free to collect plain-text passwords, and I am assuming anyone who cares about this topic will not be using basic authentication over unencrypted http. The small advantage I do see is that passwords can not be scrounged through direct access to Data.fs. In the current situation we need to: * restrict access to Data.fs on the live server * store backup tapes securely (or encrypt content) * encrypt Data.fs when copied to a backup server However, I dont think encrypting user passwords is enough. Data.fs may contain plaintext passwords for relational databases, and in many cases it contains arbitrary confidential information. Would it make more sense to encrypt whole storages?
The risk is incompatibility with HTTP digest auth, which I imagine nobody is using right now.
And incompatability with almost all other not-yet-invented authentication schemes.
2) If cPickle were to do something similar to "intern"-ing strings when loading objects from the ZODB, Zope might consume significantly less RAM on busy servers. ZODB uses lots of strings. ZODB caches cannot be shared among threads. But strings, being immutable, can be safely shared. We couldn't just intern the strings since that would make them immortal, but if we used weak references it could work.
I like this alot. Can the idea be extended to other objects which Zope treats as immutable? For example, DTMLMethod objects hold a dtml parse tree made up of cvlass instances. This must have a significant memory footprint. Toby Dickenson tdickenson@geminidataloggers.com