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

Make downloading Bags more secure #17

Open
mjordan opened this issue May 7, 2019 · 6 comments
Open

Make downloading Bags more secure #17

mjordan opened this issue May 7, 2019 · 6 comments
Labels
enhancement New feature or request

Comments

@mjordan
Copy link
Owner

mjordan commented May 7, 2019

#15 introduced a feature that allows Bags to be downloaded. However, anyone who knows the URL to the directory where the Bags are exposed for downloading has access to all Bags, which is obviously very insecure.

We need a way of allowing Bags to be downloaded that provides more robust security.

@mjordan mjordan added the enhancement New feature or request label May 7, 2019
@mjordan
Copy link
Owner Author

mjordan commented May 7, 2019

Some constraints:

  • If the files are just exposed for download, we can't use Symfony's IP-based firewall since the user could be anywhere.
  • We want to avoid adding user-management functionality to Islandora Bagger.
  • Bags should not hang around longer then they need to. Pruning the downloads directory frequently is probably a very good idea. However, this would mean that the user downloading the Bag needs to know how long it will be available.

@whikloj
Copy link
Contributor

whikloj commented Dec 3, 2019

Token download? We had something like this in our Document Delivery department where the patron would get emailed a token and could use it to download the item once (maybe twice) and there was also a deadline. So once the token was used up or the deadline passed it was removed.

@nikathone
Copy link

I am currently trying to containerize the Islandora bagger and I was thinking if we bind mount the Drupal private directory in the bagger container it could save the bags in a specific directory and a Drupal module could be responsible of downloading and cleaning up that directory.

I will update my finding later today but please let me know if this is not a good approach. Thanks again for all the work on this module.

@mjordan
Copy link
Owner Author

mjordan commented Mar 25, 2020

@nikathone sounds good to me. https://github.com/mjordan/islandora_bagger_integration already exists so it could manage access to the bags in the private directory. Whatever it does should not be required but configurable by the site admin. I am happy to work building this into that module if you want. However I have one question - are use of the private file system and the public filesystem mutually exclusive or can we do what you are describing and still allow for use of the public filesystem at the same time?

@nikathone
Copy link

are use of the private file system and the public filesystem mutually exclusive or can we do what you are describing and still allow for use of the public filesystem at the same time?

Drupal allows user to set and use both directories in the settings.php See https://git.drupalcode.org/project/drupal/-/blob/8.8.x/sites/default/default.settings.php#L501 and /admin/config/media/file-system for more information.

@nikathone
Copy link

Right now for testing purposes I am setting the drupal private path under /home/vagrant/drupal_private_files. Since the vagrant home directory for islandora claw playbook is synced with the vm host under <path-to-islandora-claw-playbook> that will add a drupal_private_files on the host. I can then bind mount this folder inside the bagger container.

For production server configured with the playbook the private files will be set on the host and both Drupal and container should have access to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants