omeka / plugin-Reports

Generates report documents from Omeka items.
6 stars 5 forks source link

Cannot download HTML report file #19

Closed miniol closed 9 years ago

miniol commented 10 years ago

I'd like to refresh an issue that was already mentioned in #14

rsanc77 wrote:

The permission error is an environment problem where the file is created with   restricted permissions.

patrickmj wrote:

If I'm understanding this right, someone should be able to change the permissions on the server, and it isn't really a bug in Reports.

The problem is, that 'someone' should change the HTML report file every time it is generated. The files in /files/reports directory are generated with different rights, depending on the file format:

The effect is that I can download the ZIP file containing PDF report but I can't download the HTML report file, since this is not readable.

Is it really an environment problem?

BTW, all the files added to objects have permissions set to 0644, so they can be opened in the browser.

toxicgumbo commented 9 years ago

Until it's explicitly stated in the documentation that HTML reports are considered confidential and can only be directly manipulated by a system administrator on the server they're generated on--which one might not have direct access to--then this is most definitely a bug in Reports' handling of file creation. It's not clear why this issue remains open and unresolved, formally, over a year later. The contributed hotfix is reasonable and simple.

zerocrates commented 9 years ago

To be clear, this isn't something that affects all servers, which is why the previous issue that mentioned this called it an environment-specific problem.

The fundamental issue here is that it's not totally clear what's happening differently here to have the permissions work correctly for the zip files and not the HTML.

A change in PHP's umask on some servers would make sense, but in my testing, ZipArchive also respects PHP's set umask, so that doesn't account for why the HTML is the only "problem child." It's possible this behavior is different between different versions of PHP, though.

Basically, I'm hesitant (slash unwilling) to apply the band-aid of manually setting the mode for the generated file here without some understanding of why the same isn't required of the PDF/Zip/etc. outputs.

zerocrates commented 9 years ago

Okay, it looks like we've finally figured out that this just comes from the use of tempnam, which sets restrictive permissions by default.