Media is still "live" after its been sent to the recycle bin

[sussexrick]

Originally logged as http://issues.umbraco.org/issue/U4-7258 and there are further comments there. The issue still exists in 7.12.2.

Media sent to the recycle bin shouldn't continue to have a accessible URL. Even if all links to a media item are removed from the website it can still be found and viewed via Google, even though authors believe they have deleted the file from the site.

What did you expect to happen?

The url become unavailable, media moved to an inaccessible area of the file system.

What actually happened?

File still available on the saved URL.

[nul800sebastiaan]

Thanks, this is a great feature request!
I would hesitate in moving files around:

1. In order to be able to undo a trashing, you'd need to move them somewhere predictable, which may become guessable and thus still accessible
2. Moving files around sometimes fails and you would want this to work without fail

It would be good to investigate if it would be possible to make a really (really) well-performing httpmodule that could block downloads of files if they are in the trash. However, this would mean that you'd need to always do a reverse query on each filename, find the media item and make sure it's not trashed. We would love to see if this can be done in a performant way. This also might pave the way for having support for protected media items in the core at some point.

I've marked as "Up for grabs" so that you or someone else coming along could create a pull request for it.

[abjerner]

A HTTP module would be lovely, but a solution should also take custom file system providers into consideration - eg. if the media files are hosted on Azure, a HTTP module won't catch the requests.

So moving the files to a special folder might still be the best option, although the new folder name should not be predictable.

[nul800sebastiaan]

@abjerner Sure! I was under the impression that that's how the Azure Blob Storage Provider worked but I see that there's no HTTP module there. Perhaps it is then best to add good error messages when attempting to trash things with an error occurring (when not able to move 1 or more media items).

Furthermore, maybe it's possible to move images to a directory based on their uniqueId (stored in the umbracoNode table). I don't think this GUID doesn't normally get exposed publically.

Some input from @Shazwazza or @zpqrtbnk would be good here too!

[abjerner]

@nul800sebastiaan IIRC it depends on configuration whether visitors will see the normal media URL or be redirected to the URL in blog storage.

For images, it's also worth noticing that there may be cached versions of the image (eg. when shown through the image cropper) - either locally on disk or in blob storage depending on setup.

[sussexrick]

A comment in the old tracker suggests putting a web.config file in the media folder to deny downloads. I think that could work, implemented via the IFileSystem2 so that other providers like Azure could take a different approach if they need to. The back office could still show the media items by using a different URL, one that checks for an authenticated user then reads the file from the IFileSystem2 rather than a direct download that would be blocked by the web.config.

@nul800sebastiaan I looked at media folder names a year ago for http://issues.umbraco.org/issue/U4-2412 and I think the work to use media GUIDs for the folder names has already been done by @zpqrtbnk in #1454, where he says:

"supports a new experimental mode where the media directory depends on the content/media item guid and the property guid (so is deterministic). It cannot be enabled before v8, probably"

That PR talks about the code being in MediaHelper, but I found it in MediaFileSystem.GetMediaPath() (https://github.com/umbraco/Umbraco-CMS/blob/c09cd95eb6a9faa587f81afb79d543652c3f48bd/src/Umbraco.Core/IO/MediaFileSystem.cs) where it's disabled by:

public const bool UseTheNewMediaPathScheme = false

[JimBobSquarePants]

The Azure Provider actually deletes the file outright and doesn't move anything to the recycle bin. I'm actually a little surprised no one has complained about this.

https://github.com/JimBobSquarePants/UmbracoFileSystemProviders.Azure/blob/b4ad41e2a47af2287929b63f70d2009d0564c97f/src/UmbracoFileSystemProviders.Azure/AzureFileSystem.cs#L364

Whatever changes to media storage are implemented we need it to fix umbraco-community/UmbracoFileSystemProviders.Azure#106

Something in 7.6 broke our implementation.

[dawoe]

Hi @JimBobSquarePants

If I remember correctly the DeleteFile method from the FilesystemProvider is only called when a media item is removed from the recycle bin. Which is how it should work, because you can restore items from the media bin and the file should still exist.

Dave

[JimBobSquarePants]

@dawoe Ah yes, that's correct. It's been a while since I wrote the code.