In our site we have deleted items from the media section, then gone into the recycle bin and deleted them (individually by right click then delete, not by emptying the recycle bin). The thing is, some items are still accessible using the url (e.g. http://www.mysite.com/media/347898/This-Is-A-File.pdf).
Is this a known issue? Is there any way to fix it?
Perhaps you need to update the examine index, If you go into the developer section, you will find a Examine Management dashboard. In the Indexers section you can go to "Index info & tools" for each index and click "Rebuild index".
Unfortunately, rebuilding the index did not solve the issue.
What is supposed to happen? I assume you deleting an item in the media section causes it to move into the recycle bin, at which point the file remains on the file system. But after removing the item from the recycle bin (or emptying the recycle bin), are the files supposed to be cleared from the file system? If so, would any issues be reported in the error log table?
I can try using the F.A.L.M. package, but would really like to be able to identify the root cause of the problem. We do use the Media Protect package, but because the media items have been deleted from the database, I can't see that it's possible to tell if they were protected.
Okay, I don't see any error reported in the umbracoLog table stating that there was an error trying to delete media files from the file system. The media files that still exist on the file system have no corresponding cmsContentXml table record referencing them (via the umbracoFile element).
I can only assume, therefore, that Umbraco quite happily removes media items from the database whilst leaving their files on the file system, without reporting any error as to why it couldn't remove it from the file system. That's pretty bad practice from a security perspective, and also a hard disk usage perspective.
So if someone accidentally uploads a sensitive file, then removes it from the CMS, there's a chance their image or document will still be accessible as it will still exist on the file system.
Looks like I'll have to try the F.A.L.M. package and see if / how it removes the files.
Does Umbraco know that the request has been made to the webroot/Media folder on the file system, even though the media item requested is not in the database (or Umbraco cache)?
With that in mind, are you saying I could use the MediaProtect.Requesting event to check if the file exists in the database or cache, and if it doesn't then delete the media item folder? How would I do this without knowing the media item id to look it up (the umbracoFile path does not contain the actual media id, it's some other id that I have not been able to find in the database)? And would the Requesting event fire for media items that are not in a protected section?
The only way I can see to actually check if the file is referenced in the CMS is to run a database query against the entire cmsContentXml using a LIKE in the where clause, e.g:
SELECT COUNT(*) FROM cmsContentXml WHERE [xml] LIKE '%/media/347898/%'
But this would be extremely slow, especially running it against a large website, and even more so when there are many images on a page.
I'm hoping I'm missing something. It would be great if you could tell me there is a better way! :-)
You could run the same query against the CMSPropertyData table the NVarChar column contains the item when exist. Indeed this is a bit slower but if you cache the result it works fine. Media protect is doing that also.
Deleted Media Items Still Accessible
Umbraco 6.1.5
In our site we have deleted items from the media section, then gone into the recycle bin and deleted them (individually by right click then delete, not by emptying the recycle bin). The thing is, some items are still accessible using the url (e.g. http://www.mysite.com/media/347898/This-Is-A-File.pdf).
Is this a known issue? Is there any way to fix it?
Thanks!
This is still a problem for us. Is this an unknown issue?
Hi Mark,
Perhaps you need to update the examine index, If you go into the developer section, you will find a Examine Management dashboard. In the Indexers section you can go to "Index info & tools" for each index and click "Rebuild index".
Hope this helps,
/Dennis
Hi Mark,
Don´t know if this F.A.L.M housekeeping package can help you the images that still are accessible although they are deleted.
http://our.umbraco.org/projects/backoffice-extensions/falm-housekeeping
Hope this helps,
/Dennis
Hi Dennis
Unfortunately, rebuilding the index did not solve the issue.
What is supposed to happen? I assume you deleting an item in the media section causes it to move into the recycle bin, at which point the file remains on the file system. But after removing the item from the recycle bin (or emptying the recycle bin), are the files supposed to be cleared from the file system? If so, would any issues be reported in the error log table?
I can try using the F.A.L.M. package, but would really like to be able to identify the root cause of the problem. We do use the Media Protect package, but because the media items have been deleted from the database, I can't see that it's possible to tell if they were protected.
Okay, I don't see any error reported in the umbracoLog table stating that there was an error trying to delete media files from the file system. The media files that still exist on the file system have no corresponding cmsContentXml table record referencing them (via the umbracoFile element).
I can only assume, therefore, that Umbraco quite happily removes media items from the database whilst leaving their files on the file system, without reporting any error as to why it couldn't remove it from the file system. That's pretty bad practice from a security perspective, and also a hard disk usage perspective.
So if someone accidentally uploads a sensitive file, then removes it from the CMS, there's a chance their image or document will still be accessible as it will still exist on the file system.
Looks like I'll have to try the F.A.L.M. package and see if / how it removes the files.
Hi Mark,
It's because of a bug in Umbraco that the files sometimes still exists on disk. I think there are already a few workitems logged.
Maybe you can use the event system of Media protect to check if the media item exists in the database and block access when it doesn't?
Best,
Richard
Hi Richard
Thanks for the response. So just to confirm:
Does Umbraco know that the request has been made to the webroot/Media folder on the file system, even though the media item requested is not in the database (or Umbraco cache)?
With that in mind, are you saying I could use the MediaProtect.Requesting event to check if the file exists in the database or cache, and if it doesn't then delete the media item folder? How would I do this without knowing the media item id to look it up (the umbracoFile path does not contain the actual media id, it's some other id that I have not been able to find in the database)? And would the Requesting event fire for media items that are not in a protected section?
The only way I can see to actually check if the file is referenced in the CMS is to run a database query against the entire cmsContentXml using a LIKE in the where clause, e.g:
SELECT COUNT(*) FROM cmsContentXml WHERE [xml] LIKE '%/media/347898/%'
But this would be extremely slow, especially running it against a large website, and even more so when there are many images on a page.
I'm hoping I'm missing something. It would be great if you could tell me there is a better way! :-)
Hi Mark,
You could run the same query against the CMSPropertyData table the NVarChar column contains the item when exist. Indeed this is a bit slower but if you cache the result it works fine. Media protect is doing that also.
Hope this helps,
Richard
Hi Richard, I'll take a look at that table. Thanks. When you say "cache the result", do you mean storing it in a Lucene index?
I use an in memory cache the fastest way.
I found Umbraco version 8.12.2 still has this problem. I already rebuild the index but still, the file URL works. Any help?
Thanks in advance.
is working on a reply...