git.oblomov.eu Git - ikiwiki/blob - doc/todo/fileupload/discussion.mdwn

   1  * Limits to size of files that can be uploaded. Prevent someone
   2    spamming the wiki with CD isos..
   3
   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.
  10
  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.
  15
  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.
  20
  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.
  25
  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.
  31
  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?)
  36
  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]]
  44
  45