Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add FileStorage abstraction for handling remote file storage #193

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

coordt
Copy link

@coordt coordt commented Feb 1, 2017

Instead of using Python's open() and assuming that the files are stored locally, use the file storage abstraction to open the file.

This also allows the specification of a separate file storage class.

@stephenmcd
Copy link
Owner

Thanks for this, it definitely needs fixing but I think a much simpler approach would be to just use the default storage engine configured. Would you like to look at that?

@stephenmcd stephenmcd closed this Feb 1, 2017
@coordt
Copy link
Author

coordt commented Feb 1, 2017

This does do that. If you don't specify a storage class, it uses the default. Why limit the options when it is just as easy to allow both?

@stephenmcd
Copy link
Owner

Yeah but now there's 3 options instead of 1, seems like overkill.

@stephenmcd
Copy link
Owner

Also I just realised on reviewing this a bit further - the whole idea of FORMS_BUILDER_UPLOAD_ROOT and using filesystem storage is to protect the files from being publicly accessible, so I'm not sure how good an idea it would be to bypass that.

@coordt
Copy link
Author

coordt commented Feb 2, 2017

Actually, your current solution only works if you have one application server and don't store your uploads on remote media, like Amazon S3. As soon as you have to scale to multiple app servers or want to store your uploads remotely, your solution completely fails, and people must fork your project, as we did.

In order to keep things safe, and flexible, the better option is to use Django's Storage API to allow the users to set up the storage as they need to. A custom Storage class only need set a new place to save the files that isn't part of MEDIA_ROOT. The Storage API can do everything your existing FORMS_BUILDER_UPLOAD_ROOT can do and more.

@stephenmcd
Copy link
Owner

You're right. So I guess the approach is on the right track, it probably needs a bit more work though.

We should probably have one location in the code that returns the file storage object, which is either file system storage when FORMS_BUILDER_UPLOAD_ROOT is defined, or the custom storage.

I think defaulting back to the default storage is probably not what we want, and that if either of the settings aren't defined, we raise some kind of error. (I realise this problem existed already.)

I guess we should point out in the docs as well that one of the settings is required, and why (so that the files aren't publicly accessible).

@@ -23,6 +24,9 @@
# The absolute path where files will be uploaded to.
UPLOAD_ROOT = getattr(settings, "FORMS_BUILDER_UPLOAD_ROOT", None)

# The File Storage class to use, uses default file storage if None
FILE_STORAGE = get_storage_class(getattr(settings, "FORMS_BUILDER_FILE_STORAGE", None))

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following on from our discussion - perhaps this could default to a storage class that exists in this app, that merely uses UPLOAD_ROOT inside its init, and raises an error there if the setting isn't defined. That way all the access to the storage class can happen directly via FORMS_BUILDER_FILE_STORAGE.

@stephenmcd
Copy link
Owner

Also some work to be done in https://github.com/stephenmcd/django-forms-builder/blob/master/forms_builder/forms/admin.py#L187 where (if I recall) admin users can download uploaded files from links with emails they're sent.

@stephenmcd stephenmcd reopened this Feb 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants