[announce] Local File System product
I've created a product called Local File System which allows you to mount directories from the local file system in your Zope server and serve the files as regular Zope objects. It also allows browsing directory contents. This is currently a development release so I wouldn't recommend installing it on a production server. Anyone interested in this sort of thing please give it a try and let me know what you think. It's available at http://www.zope.org/Members/jfarr/LocalFS Thanks, -jfarr
Jonothan Farr wrote:
I've created a product called Local File System which allows you to mount directories from the local file system in your Zope server and serve the files as regular Zope objects. It also allows browsing directory contents. This is currently a development release so I wouldn't recommend installing it on a production server. Anyone interested in this sort of thing please give it a try and let me know what you think. It's available at http://www.zope.org/Members/jfarr/LocalFS
Good work. I have seen a lot of messages on this list requesting just such a product. It is much simpler than a similar product that I was trying to build. I was trying to get Zope to publish the file objects directly. Your approach is to treat the file system like a ZSQLMethod -- the programmer accesses it through DTML calls -- much less fragile, more secure. Issues to address: security (not as much of a problem as with my read/write product) filtering -- e.g. I want to see only .HTML files (easy) content-type -- why does everyone have to reinvent mime.types? Apache, Python, Zope (File/Image), Confera, Squishdot, and LocalFS each has its own hard coded set of favorite mime types that get recognized by suffix. Maybe someone (maybe me) could create a mime-types product that solves this problem once. The client could point to a preferred type-registry, a file name, and the first 200 or so bytes of the content, and get back a mime type, a human readable name, and a set of icons. possible future extensions: Uploading files to the file system. redirects -- e.g. for large multimedia files access to application-level file systems -- e.g. zip|tar|cpio files, CD images, IMAP folders this could be done by abstracting the file system in a way similar to ZServer/medusa/filesys.py.
Issues to address: security (not as much of a problem as with my read/write product)
The only security issue I've addressed is that '..' is not allowed as a directory name, it will throw a ValueError. Also, of course the Zope server has to have permissions to access any files that it tries to read through LocalFS. If anyone can think of any others please let me know.
filtering -- e.g. I want to see only .HTML files (easy)
It should be pretty easy to write a DTML method to do this, using methodBrowse.dtml as a reference. To use this right now you would have to inherit the method from a folder above the file system object (or hack the source). I thought about making the file system object a container just so you could add your own methods and such. The problem is that any objects contained by the file system object would potentially mask files in the local file system, so I decided against it.
content-type -- why does everyone have to reinvent mime.types? Apache, Python, Zope (File/Image), Confera, Squishdot, and LocalFS each has its own hard coded set of favorite mime types that get recognized by suffix.
LocalFS actually uses that standard Zope mechanisms for determining the content type. It just lets the Image.File or Image.Image object figure out its own content type. I did add a hook for overriding the content type with a static list because 1) I didn't like some of the content types that Zope was deciding on, i.e. application/octet-stream for .rm files, and 2) I plan to make this a feature of the user interface to allow administrators to override content types.
Maybe someone (maybe me) could create a mime-types product that
solves
this problem once. The client could point to a preferred type-registry, a file name, and the first 200 or so bytes of the content, and get back a mime type, a human readable name, and a set of icons.
I like that idea. Go for it!
possible future extensions:
Uploading files to the file system.
redirects -- e.g. for large multimedia files
access to application-level file systems -- e.g. zip|tar|cpio files,
CD
images, IMAP folders this could be done by abstracting the file system in a way similar to ZServer/medusa/filesys.py.
Those are some great ideas! Thanks for all the feedback. -jfarr ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi! I'm a signature virus. Copy me into your .sig to join the fun! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Mon, Oct 25, 1999 at 06:12:12PM -0700, Jonothan Farr wrote:
Issues to address: security (not as much of a problem as with my read/write product) The only security issue I've addressed is that '..' is not allowed as a directory name, it will throw a ValueError. Also, of course the Zope server has to have permissions to access any files that it tries to read through LocalFS. If anyone can think of any others please let me know.
I was planning on writing a product like this myself (but of course didn't quite get past just thinking about it in my head! I have so many projects like that!) What I was planning on doing for security was having an "access" file in the products directory that contained a list of directories and a list of the files (allowing wildcards) that you were allowed to access in _that_ directory. It was going to default to only letting you read txt and log files in the product directory itself (defined by .). You could also add roles to this file. Basically you would strip out any &;: and other weird characters from the directory name the product was trying to access and then, if it wasn't in the list, don't bother looking any further. If it was, then check that they are allowed to look at the file. Basic reasoning is you do _not_ want people looking at any file they like (like config files and password files), so if the access restrictions are actually on your hard drive then if someone manages to crack your Zope installation and get management permissions on it they still can't access anything on your box unless they've cracked it independantly.
-jfarr
-- Evan ~ThunderFoot~ Gibson ~ nihil mutatem, omni deletum ~ May the machines watch over you with loving grace.
On 25 Oct 1999 20:50:01 -0500, Evan Gibson wrote:
On Mon, Oct 25, 1999 at 06:12:12PM -0700, Jonothan Farr wrote:
Issues to address: security (not as much of a problem as with my read/write product) The only security issue I've addressed is that '..' is not allowed as a directory name, it will throw a ValueError. Also, of course the Zope server has to have permissions to access any files that it tries to read through LocalFS. If anyone can think of any others please let me know.
I was planning on writing a product like this myself (but of course didn't quite get past just thinking about it in my head! I have so many projects like that!) What I was planning on doing for security was having an "access" file in the products directory that contained a list of directories and a list of the files (allowing wildcards) that you were allowed to access in _that_ directory. It was going to default to only letting you read txt and log files in the product directory itself (defined by .). You could also add roles to this file.
My 'file access' product creates Zope folders which correspond to directories and other interesting objects. These Zope folders can use the std zope acl_users (or whatever) and can also contain methods and products in the Zope database specific to that directory or file tree. This allows you to create different meta-data for the same directories, depending on how they are accessed from Zope (different subdir folders pointing at the same filesys path).
participants (4)
-
Evan Gibson -
Jonothan Farr -
kent＠tiamat.goathill.org -
Terrel Shumway