implement password security for files
Ticket
+issues
...and images.
+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