search

danielquinn / django-encrypted-filefield

Encrypt uploaded files, store them wherever you like and stream them back unencrypted
GNU General Public License v3.0
65 stars 22 forks source link

DEFF_FETCH_URL_NAME should not be required #2

Closed cscheng closed 7 years ago

cscheng commented 7 years ago

It's safe to assume that when a user uploads a file that at some point in time this file will be downloaded. However, the system check for this is probably too strict for several reasons:

  1. When you do not (yet) have created a fetch URL with an accompanying view, runserver will not run at all. This is a bit cumbersome when you want to add the EncryptedFileField first, and implement the views at a later time.
  2. The check itself is too rigid, as it does not allow other kwargs for the fetch URL. For example, if you want something like /users/<user_id>/files/<file_id> this URL cannot be reversed by the check.
  3. There are probably some scenarios where the uploaded files are not intended to be downloaded. For example, a data file that is processed and only stored encrypted for archival purposes.

My suggestion would be to drop the DEFF_FETCH_URL_NAME requirement, as an example URL + view in the docs would suffice for most developers.

danielquinn commented 7 years ago

I'm so sorry for not responding to this sooner. I can only assume that the message got lost among all of the other GitHub noise I get.

You make all very good points. If you have some code to address this, I'm happy to field a pull request. Otherwise, I'll try to look into this in the near(er) future.

cscheng commented 7 years ago

No problem. I have actually moved on to other projects, so I won't have time to contribute with a PR any time soon. Feel free to close this issue.

danielquinn commented 7 years ago

All patched! Thanks for the suggestion, and for your patience :-)