If you attach a file that isn't a supported filetype you get a bad error message.
Closed this issue · 5 comments
I was recently testing the our collecting form with larger files and I was just generating a large file with dd:
dd if=/dev/zero of=~/tmp/20M bs=1m count=20
and then attaching this file as an upload. However when Omeka attempted to process this submission it generates a permission error. It turned out even small files generated with this method resulted in the same error. However a 18MB JPG would upload file.
I think it should tell the user that the supplied file isn't supported.
The message that's in the logs is:
[Wed Nov 15 11:21:21.109255 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: PHP message: exception 'Omeka\\Mvc\\Exception\\PermissionDeniedException' with message 'Permission denied for the current user to access the submit action of the Collecting\\Controller\\Site\\Index controller.' in /var/www/somehost/omeka-s-1.0.0-rc.1/application/src/Mvc/MvcListeners.php:430, referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109289 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: Stack trace:, referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109293 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: #0 /var/www/somehost/omeka-s-1.0.0-rc.1/vendor/zendframework/zend-eventmanager/src/EventManager.php(322): Omeka\\Mvc\\MvcListeners->authorizeUserAgainstController(Object(Zend\\Mvc\\MvcEvent)), referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109297 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: #1 /var/www/somehost/omeka-s-1.0.0-rc.1/vendor/zendframework/zend-eventmanager/src/EventManager.php(179): Zend\\EventManager\\EventManager->triggerListeners(Object(Zend\\Mvc\\MvcEvent), Object(Closure)), referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109300 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: #2 /var/www/somehost/omeka-s-1.0.0-rc.1/vendor/zendframework/zend-mvc/src/Application.php(332): Zend\\EventManager\\EventManager->triggerEventUntil(Object(Closure), Object(Zend\\Mvc\\MvcEvent)), referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109312 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: #3 /var/www/somehost/omeka-s-1.0.0-rc.1/index.php(21): Zend\\Mvc\\Application->run(), referer: http://somehost/s/lest-we-forget/page/add
[Wed Nov 15 11:21:21.109316 2017] [:error] [pid 854:tid 140106514028288] [client 129.67.101.138:50689] FastCGI: server "/usr/lib/cgi-bin/php5-fcgi" stderr: #4 {main}, referer: http://somehost/s/lest-we-forget/page/add
What happens if you try to upload the same file normally, through the backend?
I get the expected errors:
Error validating "20M". Cannot store files with the media type "application/octet-stream".
Error validating "20M". Cannot store files with the resolved extension "bin".
Yep, through the admin backend I get that error:
Error validating "1M". Cannot store files with the media type "application/octet-stream".
Error validating "1M". Cannot store files with the resolved extension "bin".
I just would have expected the collecting frontend to show a message saying it's not a supported file type rather than generating a 500 error and leaving a what seems unrelated message in the logs. In lots of ways it's more important for the collecting page than the admin interface as the people using it may not understand the limits of the software.
The reallow-controller branch should fix the issue. Put simply, the exception is raised due to some unexpected behavior of ACL's removeAllow().
After closer investigation we discovered a bug in S core that's responsible for the PermissionDeniedException you're seeing. We've patched the bug in the develop branch. An upcoming bug fix release should resolve this issue without having to apply the changes currently in the reallow-controller branch.