Details
-
Bug
-
Resolution: Fixed
-
Medium
-
4.0.5, 4.0.7, 4.1.2, 4.1.4, 4.2.0
-
None
Description
Files in objects that are moved to trash are still available using direct URL access. They should not be. The patch fixes this by renaming the files when trashing them.
The patch only covers eZBinaryFileType. The same fix also needs to be done for eZImageType and eZMediaType. I can do this if the principle in the patch is approved.
The patch adds the function trashStoredObjectAttribute() to the eZDataType API, following the same logic as deleteStoredObjectAttribute(). Only those datatypes that need any trashing changes will have to implement it, and that means the attributes that store files (binaryfile, image and media).
No changes are needed on restoring from trash, unless we consider it important that the filename is reverted back to the original - I don't see why this should matter. It makes things a bit more complicated.
*) This is slightly more complex as we need to remove image variations, as well as rename the original.
Steps to reproduce
- Create a content object of the File class
- Find the direct URL to the file in the var directory (e.g. by grepping for the file content in var)
- Load the file in a browser using http://hostname.tld/var/path/to/file.ext
- Move the File object to the trash
- Reload the file in a browser using http://hostname.tld/var/path/to/file.ext. The file is still available, even after clearing browser caches.
Attachments
Issue Links
- relates to
-
EZP-17781 image aliases not restored when restoring object from trash
- Closed