I was surprised by this when working on a recent side project.
The API for direct upload allows anyone to upload a file to the storage and to retrieve said file using its signed ID, which is returned by the API.
My guess is that there are many sites out there where this open door has not been closed. Especially since the guide is very vague about how to secure the controllers and it does not mention the issues with direct upload.
Hmm. I usually find that when I'm surprised by something in Ruby/Rails, as I come to an understanding of what's going on, it's an "of course that's how it works" situation.
I suspect, but don't know, that ActiveStorage works on top of serving assets from the `public/` folder, so it makes sense that it's skipping controller `before_actions`. And, I guess it does makes sense that it's skipping those, since there's also otherwise not a controller action to write to handle serving the asset.
Hmm - so the usual flow would be that the controller renders something that includes the asset URL (HTML or JSON), and then the page loads the asset. The URL will be "security through obscurity".
I guess, if I wanted to change this behavior, I'd want a gem (or a quick pattern) that provides a controller that'll actually serve the asset (and not just the asset URL), which in turn would allow me to plug in actions, etc; then you disable the default routes, and you're done.
2 comments
[ 2.8 ms ] story [ 17.9 ms ] threadThe API for direct upload allows anyone to upload a file to the storage and to retrieve said file using its signed ID, which is returned by the API.
My guess is that there are many sites out there where this open door has not been closed. Especially since the guide is very vague about how to secure the controllers and it does not mention the issues with direct upload.
I suspect, but don't know, that ActiveStorage works on top of serving assets from the `public/` folder, so it makes sense that it's skipping controller `before_actions`. And, I guess it does makes sense that it's skipping those, since there's also otherwise not a controller action to write to handle serving the asset.
Hmm - so the usual flow would be that the controller renders something that includes the asset URL (HTML or JSON), and then the page loads the asset. The URL will be "security through obscurity".
I guess, if I wanted to change this behavior, I'd want a gem (or a quick pattern) that provides a controller that'll actually serve the asset (and not just the asset URL), which in turn would allow me to plug in actions, etc; then you disable the default routes, and you're done.