notempty plugin error if fileupload plugin is also used

[Bauer]

I have a list/form that uses a repeat group. In both groups there is a dropdown element. I intentionally made the default value of the dropdown elements empty and use the 'notempty' plugin to require that a selection be made from those dropdowns.

If a dropdown selection is not made, the 'notempty' validation works - but I also get the error shown below.

This is the same form where I am using a fileupload element.
So it looks like, for some reason, the 'notempty' validation is also being checked against the fileupload file!

Backtrace from warning 'fopen(): Filename cannot be empty' at /home/mydomain/public_html/libraries/joomla/filter/input.php 623:

/home/mydomain/public_html/index.php 49 calling execute()
/home/mydomain/public_html/libraries/cms/application/cms.php 257 calling doExecute()
/home/mydomain/public_html/libraries/cms/application/site.php 230 calling dispatch()
/home/mydomain/public_html/libraries/cms/application/site.php 191 calling renderComponent()
/home/mydomain/public_html/libraries/cms/component/helper.php 380 calling executeComponent()
/home/mydomain/public_html/libraries/cms/component/helper.php 405 calling require_once()
/home/mydomain/public_html/components/com_fabrik/fabrik.php 181 calling execute()
/home/mydomain/public_html/libraries/legacy/controller/legacy.php 728 calling process()
/home/mydomain/public_html/components/com_fabrik/controllers/form.php 226 calling validate()
/home/mydomain/public_html/components/com_fabrik/models/form.php 2246 calling validate()
/home/mydomain/public_html/plugins/fabrik_element/fileupload/fileupload.php 972 calling get()
/home/mydomain/public_html/libraries/joomla/input/files.php 83 calling isSafeFile()
/home/mydomain/public_html/libraries/joomla/filter/input.php 623 calling fopen()

 

[cheesegrits]

Doesn't look like that has anything to do with the notempty.

The issue seems to be that when we do ...

$files = $input->files->get($name, array(), 'cmd');

... in the upload element's built in validation. Then JInputFiles::get() does ...

$isSafe = JFilterInput::isSafeFile($results);

... even if the $_FILES['whatever']['name'] is empty (eg. a file wasn't uploaded), which then causes isSafeFile() to try and open an empty string as a file ...

$fp = @fopen($tempName, 'r');

And obviously that @ is no longer suppress that error on your installation.

I'm going to submit a PR on J! to fix that (skip the isSafeFile if no ile uploaded), and in the meantime I'll see if I can come up with some nasty hack in our code to try and avoid it.

-- hugh

 

[cheesegrits]

The only other option is to specify 'raw' as the option, which would skip the safety check when files are actually uploaded.

-- hugh

 

[cheesegrits]

BTW what version of PHP are you running?

I'm not sure why the @fopen() isn't suppressing that warning on your system.

-- hugh

 

[Bauer]

BTW what version of PHP are you running?

I'm not sure why the @fopen() isn't suppressing that warning on your system.

-- hugh

I'm using php v.7.0.9
Even if the error is suppressed, it would still stop the form from being submitted.
I know that all I have to do is 'forget about it' and try the same menu option again. But it confuses the user that they can't really exit the page. Errors make me nervous - and they make users even more nervous or frustrated - because they think they did something wrong or maybe messed up their data.

The only reason I insisted it was the notempty plugin is because if I disable the plugin, it doesn't check for the empty filename in the fileupload element when the form is saved (and why should it? - its optional).

 

[Bauer]

I just switched from using notempty to isnot (and just left 'Is not' blank) - and that works just fine.
That notempty plugin has a lot to be desired - I usually avoid it like the plague - but I thought this case was 'simple enough'.

 

[cheesegrits]

I'm using php v.7.0.9
Even if the error is suppressed, it would still stop the form from being submitted.
I know that all I have to do is 'forget about it' and try the same menu option again. But it confuses the user that they can't really exit the page. Errors make me nervous - and they make users even more nervous or frustrated - because they think they did something wrong or maybe messed up their data.

The only reason I insisted it was the notempty plugin is because if I disable the plugin, it doesn't check for the empty filename in the fileupload element when the form is saved (and why should it? - its optional).

Right, but that's nothing to do with Fabrik, that I can figure out. We're just doing what we are supposed to do.

First thing the upload element's built in validation has to do is fetch the $_FILES input, to see whether we have a file being uploaded, so we can check for file type, size, name clashes, etc. If there was no file uploaded, we just return true, do not pass Go, do not collect $200.

And in J! , fetching the $_FILES input is done with $input->files->get(), same as you'd use $input->get() on any request/post vars. And, as usual, part of using J!'s input handling is that J! does some sanitizing. For files, that involves doing safety checks on any uploaded files (unless 'raw' is specified as the $filter arg to the get()) Which involves opening them, and looking for Naughty Stuff. Have a look in ./libraries/joomla/filter/input.php, isSafeFile:

https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/filter/input.php#L501

As you can see, it never actually checks to see if the file 'name' has a file name in it. And as per the PHP reference, the $_FILES input with no file uploaded will still have entries in the array, but will have a blank name, and a 0 size.

So Joomla is trying to fopen() an empty file string, as part of the file->get() handling, and relying on the @ (STFU) operator to suppress any error msgs. But for reasons unknown to me, your system is generating an error message, despite the STFU.

fopen(): Filename cannot be empty' at /home/mydomain/public_html/libraries/joomla/filter/input.php 623:

... which as you can see, is from that @fopen(). Which should be error suppressed.

I've run through and tested the notempty code, in conjunction with a dropdown, and there is absolutely nothing I can see which would cause @ to quit suppressing messages. Hell, I don't even think there is a way in PHP to make that happen, and I spent half an hour googling around on this.

About the only way round this I can come up with for now is to either ...

a) add YAFO to the upload element to "bypass safety check", which tells us to pass 'raw' as the filter to the files->get(). Something I've been meaning to do for a while, as that isSafeFile() check can be a BIG overhead when uploading large files, as it reads through the entire file, scanning it for Naughty Things. Obviously bypassing this just to work round a bug is suboptimal, but I want that option anyway, as there are circumstances where you simply don't want or need that overhead.

b) Add some manual checking of the $_FILES array before calling $input->files->get(), and don't bother if there's nothing there.

... or ...

c) both a) and b)

-- hugh