Well, I know this doesn't address most of the issues you raise, but I've used a combination of django-filebrowser, http://code.google.com/p/django-filebrowser/ , FileBrowseField and apache's x-sendfile, http://tn123.ath.cx/mod_xsendfile/, for serving restricted access files, successfully.
I found that django-filebrowser and FileBrowseField really make the admin's task of managing file uploads easier. You can make your own directory structure, even though you have to do it manually. This, of course, doesn't solve your all your issues: - the filepath (relative to a media folder) is still stored in the database, but to be honest it hasn't been an actual problem so far. - to make a file private is the administrators responsibility - the admin must upload the files to a "private" folder, secured by apache, and to serve the file you must code a view that validates the user's permissions and returns the filepath to mod xsendfile. It's not a perfect solution but it's the best I found so far, at least for my purposes :) Nuno On Mon, May 31, 2010 at 2:06 PM, [email protected] <[email protected]> wrote: > Hi All, > > The standard Django File Fields (both on models and the form > equivalent) have a number of shortcomings from my point of view / in > my field. The most important of these are: > > * The result of uploaded file fields are assumed to be "public", i.e. > served through the MEDIA url. I would rather store the files somewhere > safe and determine in my view who gets to download what. > * The filename is stored in the database, including the (potentially > long) path to the file. This in itself creates all kinds of trouble: > * What if I want to move a file? > * What if the full path is longer than 255 characters? > * What if I create (using objects) a separate directory structure? > Why is there now a global uniqueness constraint on variable names? > > As far as I see the custom storage system does not fix any of the > above problems, since it is "name" based. > > For a number of my applications I've worked around the above problems > by simply coding around it: I'm storing the filename in the DB in a > CharField, and manually read/write the file from/to disk in view > operations. I'm using the [appname]/[modelname]/[fieldname]/id as a > path. > > Obviously I'd like to factor out the above. So I tried > http://docs.djangoproject.com/en/1.2/howto/custom-model-fields/ > > I'm running into a bunch of problems: > * The 'real' django FileField does not follow the pattern from the > article above (i.e. search for to_python in the source). What's going > on here? > * As described above, I'd like to use the pk of an object to write the > file. However, the pk is not available before the save is done (at the > model level). Are there known solutions for this problem? > > What paths could you recommend for me? Are my observations on the > limitations of FileFields correct? Have some of you tried and found > (different?) solutions? > > thanks a bunch. > > regards, > Klaas van Schelven > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
