Ticket
implement password security for files+issues
...and images.
implement password security for files+solution
Web API
/<cardname>
/<cardname>.<ext> # accepts "rev" param specify revision number /files/<card_id>/<action_id>.<ext>
Examples: GET /my_paper # returns card (html page). content is download link GET /my_paper.pdf # returns file. most recent revision. browser cannot cache GET /files/~67/12345.pdf # this is what is linked to in card content. returns file. server tells browser to cache permanently.
files/:card_id/:action_id[-:size].:extension
- by default the files directory is in "local" before 1.13 and in the app root beginning with 1.13
- you can configure a custom files directory in wagn.yml with "attachment_storage_dir"
- the files should NOT be directly exposed to the webserver (eg, by putting it in the "public" directory); this would negate all the value of wagn's permission checking.
- :size only applies to images and can be any of the following: icon, small, medium, large, original
The mechanism we'll be using is described here.
The key part:
before_filter :login_required def download send_file '/home/railsway/downloads/huge.zip', :type=>"application/zip", :x_sendfile=>true end
With that, we’re done. Our rails process just make a quick authorization check and render a short response, and apache uses its own optimised file streaming code to send the file down to our users. Meanwhile, the rails process is free to go on to the next request.
The following aren't part of security, but we should either knock them out or ticket them separately:
√ 1. appropriate error messages for:
- √ errors with image resizing (checked because these installation issues should now be caught by bundle install. if somehow errors persist, they should show up via normal messager -efm)
- √ errors with exceeding (configurable) maximum file size
√ 2. if card name is blank (not set yet), prepopulate based on file name (javascript)
Question: how do we handle invalid mime types? Eg, current image is face.png, but request is for face.gif. Error msg for now?
Actually, it now redirects to the correct mime type. In the future may convert on the fly. --efm
(resetting this discussion to focus on new design above. Old discussion still available via changes tab)
massive progress.
remaining todos here:
1. js needs to handle multiple files / images in a single form
2. √ interface needs to change when file is added
3. √ error handling (above)
4. √ taking name from file (above)
--Ethan McCutchen.....Tue Dec 13 21:27:48 -0800 2011
in general, I think the use of revision ids is correct, but I think in the cases most likely to be user-manipulated urls, we should use rev (not revision) and it should be the nth revision, not the revision_id.
--Ethan McCutchen.....Tue Dec 13 21:37:54 -0800 2011
OK, I'm starting to think that we should punt on the issue of being able to handle multiple files/images in a single form until 1.8.2.
Currently files/images are not uploaded until you click submit. This is especially vital on new cards, because files are stored based on revision ids, you can't have a revision id until you've stored a revision, and you can't have a revision without cards.
We're planning to move to a model that will support revisions for unsaved cards. I'll discuss several advantages on that ticket.
The advantages for files/images are
1. this is a much more standard user story and is much better supported by existing libraries
2. relatedly, it will be simple to add some sugar, like upload bars and an upload-from-web option
3. performance will be better, because the image/file will often be uploaded by the time the form is submitted.
--Ethan McCutchen.....Wed Jan 04 13:41:42 -0800 2012
I guess the question in the meantime is whether there are user stories that make the current behavior unacceptable in the short-term. I don't really know of any. We will probably want to warn wagneers prominently.
--Ethan McCutchen.....Wed Jan 04 13:43:24 -0800 2012
going to close this. still hearing some issues with specific browsers, filetypes, and migrations, but not using this ticket to track them.
--Ethan McCutchen.....Wed Feb 01 16:29:33 -0800 2012