]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/todo/fileupload/discussion.mdwn
sandbox declutter
[git.ikiwiki.info.git] / doc / todo / fileupload / discussion.mdwn
1  * Limits to size of files that can be uploaded. Prevent someone
2    spamming the wiki with CD isos..
4 > CGI.pm has a limitation that you can't prevent someone uploading 
5 > something huge and filling up your server.
6 > However it is obviously possible to not actually put it in to the
7 > wiki if it's too large.
8 > Presumably there is also a way to limit the size of POST requests
9 > in the server.
11 * Limits to the type of files that can be uploaded. To prevent uploads of
12   virii, css, raw html etc, and avoid file types that are not safe.
13   Should default to excluding all files types, or at least all except
14   a very limited set, and should be able to open it up to more types.
16   Would checking for file extensions (.gif, .jpg) etc be enough? Some
17   browsers are probably too smart for their own good and may ignore
18   the extension / mime info and process as the actual detected file
19   type. It may be necessary to use file to determine a file's true type.
21 > I think using the extension is too risky, and as much information as
22 > possible should go in to the decision. Saving the file to disk, then
23 > checking the type before using it seems like the best approach to me,
24 > as long as the file is deleted properly.
26 > Have you any thoughts on what the interface should be? I can see three
27 > options. First add a box to the file creation page that allows you
28 > to upload a file instead of the page. The second is an upload file
29 > link that asks for a page. The last would be an attachments system
30 > that e.g. Twiki use, where the file could be uploaded as a subpage.
32 > How about the limit setting etc.? Add it as a box on the admin's
33 > preference page, allow it anywhere using preprocessor directives,
34 > or have a configuration page that only the admin is allowed to edit
35 > (and perhaps people named on the page?)
37 > The syntax of the conditionals isn't too hard, as the things that
38 > are being added fit in nicely. It might be nice to allow plugins
39 > to register new functions for them, and provide callbacks to
40 > provide a yes no answer. I'm haven't looked at the code yet,
41 > are the pagespecs uniform in all places, or is the conditional
42 > usage an extended one? i.e. can I lock pages based on date etc?
43 > --[[JamesWestby]]