[development] How to handle uploads in a secure fashion?

[Bèr Kessels]

Op dinsdag 20 juni 2006 18:10, schreef Derek Wright:
> On Jun 19, 2006, at 10:58 AM, Fabio Varesano wrote:
> > Should the munge_filename function became a file api?
>
> it should, yes, but that's complicated.  part of the
> upload_munge_filename() stuff depends on a whitelist of approved file
> extensions.  those are handled as a setting from the upload.module.
> so, to make munge* a separate function in file.inc that didn't depend
> on the upload.module, we'd need to put those settings somewhere else,
> too.  since the existing munge stuff was done in the heat of the
> moment to get 4.7.2 out, no one felt like doing that much additional
> work to make things generic, moving all this code into the file API,
> etc...

Same here, Drupals file apis should be more general.

> but, it's a pain in the neck for those of us trying to make contribs
> more secure using this stuff, since now our modules will depend on
> the upload module, even if they don't the regular upload form
> element, etc.  we should definitely consider reorganizing this code
> in 4.8.  sadly, i'm going to be unavailable for drupal hacking until
> mid july, so i can't spearhead this effort (at least not until at
> least the end of july).

I think nearly all of us agree that:
 * upload.module is a beast that has far too much low level code which should 
be APIS
 * file.inc is both limiting as limited in what it can do for you. Limiting: 
It makes some assumptions that it should not make, but let you (the coder) 
decide. Limited: it needs a lot of love. 

Though all of us seem to agree that Something Needs To Be done, none of us 
really set down to develop it. I never got further then a GRand PLan, a 
design for how it should work. But as said: never got into actually 
developing it. 

In a very very summarised way, betterupload will work like:
		v --> file hooks modules
  [file.inc]	<-->	[upload/insert modules]
	|	^-->	[download/file presentation module]
	|	^--> [file storage module]
	v			|
  [file storage]	<-----|
  [file database]

Or in words: 
 Any upload or insert module can upload or insert (from anywhere) files. 
 
 Download, or presentation modules (such as image galleries, or even simpler 
a "dowload" link with a node) can use apis to present files, without knowing 
anything about these files.

 File storage modules offer stuff like "store on remote FTP", or like "dont 
store the actual file, just store a link, but let Drupal think it has a real 
file". Or simpler stuff like "store files under files/users/Ber/filename.png. 
These modules are optional, because file.inc is smart enough to provide a 
very simple default.

 File storage and file database are default low level things to make it all 
work. No ordinary module should have to worry about this when up or 
downloading. 
 
 File hooks modules: Any type of module that wants to hook into the lifecycle 
of a file. Since files are treated as low-level-nodes (please dont start that 
thread now again!) the same lifcycle is available. Handy to make all your 
thumbnails greyscale. Or to read the ID3 tags from audio etc.

Grand Plan: http://www.webschuur.com/node/246

Bèr