Another Design Question

[Walter McGinnis]

As I have mentioned in the past, I have a group scoped application
that I'm working on.
Currently, I'm evaluating the merits of acts_as_attachment for
documents, images, audio, and video file handling.

Groups will have public files (likely the vast majority) and private files.

Acts_as_attachement allows you to specify file_system for storage and
then file_system_path, etc. You can also override the full_filename
method in your model for even more flexibility.

However, it's written with the assumption that you want to store your
files under app/public (there are workarounds for this). This is fine
for my public files, but for private ones, I would like a bit more
protection.

I know from experience that running permissions checks on every image
file, etc. is hard to scale. So here is my idea:

Public files reside in a path like this:
app/public/group_name/model_tableized_name/id_directory/file.jpg.
They have no permissions checking before being served, just like
everything else under public.

Private files reside in a path like this:
app/private/group_name/model_tableized_name/id_directory/file.jpg and
a permission check IS DONE before serving the file, but that is all.

Does this sound wise? How would you start to implement the private
file serving? Am I missing something obvious?

Cheers,
Walter

[Walter McGinnis]

Oh yeah. I found this helpful for my understanding:

http://wiki.rubyonrails.org/rails/pages/UnderstandingHowRequestsAreRouted

Files under public that exist just get served by your webserver, where
as files that are requested but don't exist under public are routed to
rails to fulfill.

Which to my mind points me at a solution something like the following
for private files:

* create a model for private files that reads file data from the
app/private/path_to_file, it may have a virtual attribute for group
set from the path

* create a private_files controller (or simply private) that only has
a show action that then has authentication and permissions checking
hooked in

* in my models for images, audio, etc. configure acts_as_attachment to
store stuff in app/private if the item.private? is true.

Holes in my thinking?

Cheers,
Walter

[Henry Maddocks]

Sounds fine. I would put all files in the private directory and serve
them myself. It would be more explicit this way and if a file changes
access rights then it's less dicking around, but that's up to you.

[Walter McGinnis]

Yeah. I hear ya. I could do that and simply set up caching under
public on for the files that are in fact meant to be public (thus
avoiding unnecessary rails processing of public files), but I kind of
like the public/private split reflected in the filesystem too.

Cheers,
Walter

[Michael Koziarski]

> Does this sound wise? How would you start to implement the private
> file serving? Am I missing something obvious?

For secure files, you've definitely got the right idea. You basically
want to do the authorization checking in rails, then ship the file
sending off to something like lighttpd. I've used mod_secdownload in
the past, there's a good intro here:

http://www.bencurtis.com/archives/2006/11/serving-protected-downloads-with-rails/

And the comments mention a few alternatives which are worth considering.

--
Cheers

Koz

[Walter McGinnis]

Perfect. Thanks Koz and Henry.

Cheers,
Walter

[Walter McGinnis]

For simplicitie's sake I'll probably go with the send_file solution in
my outlined controller for now with a comment around it saying that if
it doesn't scale (a giant file tying up a rails process, for example),
switch to something like mod_secdownload, etc.

That discussion in the comments is definitely handy.

Cheers,
Walter

[Walter McGinnis]

...and I'll be sure to make the comment a nice long run-on sentence, too.

[Walter McGinnis]

For yet another follow up:

It sounds like technoweenie has refactored acts_as_attachment into a
more modular plugin called attachments_fu which works largely the
same, but is better suited for my project.

Here's a brief summary:

http://sixty4bit.com/wp/?p=302

and the svn repository:

http://svn.techno-weenie.net/projects/plugins/attachment_fu/

Sometimes a little chat on #rubyonrails pays off.

Cheers,
Walter