Conversation
|
The implementation makes sense, but one concern I have is that this breaks existing URLs (i.e. the key is now required in the URL and old URLs won't work at all anymore). I have used direct URLs in the past to share files and now these would no longer work. So I would prefer if the key-less URLs would still work, perhaps optionally - there could be a global option "allow file downloads without login" or something. |
…uble prefix in archive path
|
@stijn-uva This looks good now. You can enable the legacy links via a general global setting. For the legacy path, we could attempt to extract the dataset key. E.g.: We could do that before checking the setting and only check if no dataset is found. Lifted from the cleanup worker. |
|
@stijn-uva, alright, merged the archive and get_result route... mostly. @sal-uva does not have the actual the dataset's result file (just key and filename of the specific archived file). We need both the result zip filename and the file path inside the zip to extract it via I also extract the zipped file and stream it as opposed to reading it into memory. Might not matter for most social media, but could cause issues with larger videos. |
this requires a dataset key (or, if provided, can use the dataset object) to ensure user has rights to files.
one annoying caveat is that PixPlot HTML files have the route hardcoded. I need to either figure out a way to circumvent that or write a migrate script. new plots will be produced correctly.
to reduce the db requests, we could memcache the dataset data and re-instantiate the dataset object with that data. dataset.refresh_owners() would still run which has its own db requests. this only really seems relevant with something like pixplot which makes many requests for various thumbs/images.