New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.7.7: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. #13887

Closed
thelounge-zz opened this Issue Dec 23, 2017 · 32 comments

Comments

Projects
None yet
@thelounge-zz

thelounge-zz commented Dec 23, 2017

4.7.7 is broken

just dispaly a table with 25 out of 98 records and 14 columns and click edit on a random record - other than 4.7.5/4.7.6 you don't get the form part but the error message below in the error_log

[23-Dec-2017 16:37:04 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:37:49 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:38:09 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
[23-Dec-2017 16:38:38 Europe/Vienna] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0

@jeff-kilbride

This comment has been minimized.

jeff-kilbride commented Dec 23, 2017

Same here. I am getting the following warning popup on every screen when I set Number of rows greater than 25. With Number of rows equal to 25, there is no warning.

screen shot 2017-12-23 at 12 24 37

I'm running on AWS Elastic Beanstalk with PHP 7.0.25.

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Dec 23, 2017

sounds like terrible inefficient ajax stuff where i don't get what the hell is going on here when you just edit a single record based on it's primary key - i wantr back the times as PMA worked completly without ajax at all

@OlafvdSpek

This comment has been minimized.

OlafvdSpek commented Jan 2, 2018

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Jan 2, 2018

@OlafvdSpek dumb trolling - when i switch everytime abug occurs in some software chnage the software i would be 365 days busy with only that

@jeff-kilbride

This comment has been minimized.

jeff-kilbride commented Jan 2, 2018

@thelounge-zz I'm having another issue with 4.7.7. (#13907) Just wondering if you are also seeing this problem.

I have reverted to 4.7.6 for now.

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Jan 2, 2018

i revert after the first problem in basic tasks like edit a single record, so 4.7.7 was only there for 2 minutes

@HLeithner

This comment has been minimized.

HLeithner commented Jan 8, 2018

anything new on this problem? even increasing the php limit to 2000 doesn't change anything on a 100*10 fields list.

@nijel

This comment has been minimized.

Member

nijel commented Jan 8, 2018

The problem is caused by using POST for all these links now what leads to massive form nesting. This has been already addressed in master and probably needs to be backported to 4.7 branch. Related commit is 3b9fb2b

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Jan 8, 2018

don't get me wrong but what needs any form nesting when you just edit a single record?
it's a design error when you pipe the whole table around for a single record with 10, 20 or 50 fields

do you developers have only test-tables with 5 records or how can it be that it took me 3 clicks with 4.7.7 to qualify it unusable (datebase -> tablename -> edit on the first record -> boom)

@nijel

This comment has been minimized.

Member

nijel commented Jan 8, 2018

This is side effect of fixing PMASA-2017-9 and apparently the embargoed patch didn't get tested on this setup.

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Jan 8, 2018

in reality this is a side-effect of massive AJAX stuff for trivial operations - you don't need anything else than the primary key and a token to display the edit form for a record on the next screen

@HLeithner

This comment has been minimized.

HLeithner commented Jan 8, 2018

ok thx, any timeframe for 4.7.8? because pr is not really compatible with 4.7.7.

@nijel

This comment has been minimized.

Member

nijel commented Jan 8, 2018

It's unrelated to AJAX - it's caused by fact that we're now using POST for any action containing SQL query (for privacy reasons), what for example are sort links on the browse page or edit links for rows. As this is done already inside <form> element, it's get transformed in extremely ineffective way including all forms. However it didn't matter so far as it was used just in few places, but it's way more visible after 4.7.7. As the code handling this was quite complex and causing problems, I've rewritten it some time ago for 4.8 (in 3b9fb2b), but that was not included in the 4.7 branch as it's quite massive change which can lead to other problems as well.

In the end the 4.7 branch is supposed to be maintenance only, however fixing security issues sometimes forces us to do bigger changes and this is always risky...

The 4.7.8 is currently scheduled on January 22.

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Jan 8, 2018

i still don't see a reason to post that massive amount of data around

just generate the form with only the needed data on demand and you should be done or wrap a form around every row which get submitted onclick

"however fixing security issues sometimes forces us to do bigger changes" - well, but not completly untested when it breaks even on a table with 25 records and a handful of fields

@nijel

This comment has been minimized.

Member

nijel commented Jan 8, 2018

The problem is that this all is done in single form, it just contains elements for all nested forms as subform[N]. I know this is bad idea, but the code is there for quite some time and was not causing problems so far. It's not just being used much more...

phpmyadmin/libraries/Util.php

Lines 1866 to 1871 in 2ceb241

$GLOBALS['subform_counter']++;
$ret = '';
$subname_open = 'subform[' . $GLOBALS['subform_counter'] . '][';
$subname_close = ']';
$submit_link = '#usesubform[' . $GLOBALS['subform_counter']
. ']=1';

Yes, I've apparently messed up testing of the security fix. It was touching pretty much all pages and I didn't test scenario which you believe is obvious, but didn't came to my mind. You are more than welcome to contribute testcase which would cover this.

We certainly could use more manpower so that such things get better tested. With current manpower I was happy that patch got at least reviewed by one peer. It can easily happen that mistakes are going through unnoticed.

@ibennetch

This comment has been minimized.

Member

ibennetch commented Jan 8, 2018

I'll chime in here to add that I also missed this during the embargoed security testing phase. I did some testing, but wasn't thorough enough to catch this. We'll get it fixed for 4.7.8.

@CyberCr33p

This comment has been minimized.

CyberCr33p commented Feb 8, 2018

Any news about this issue?

@shucon

This comment has been minimized.

Contributor

shucon commented Feb 10, 2018

I did some research about it , but couldn't find a way to fix it without editing php.ini . Any suggestions about how to get started?

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Feb 10, 2018

downgrade to previous release, make sure you ahve some http-basic auth in front of phpMyAdmin or when possible ip-restrictions - edit php.ini because of some broken release of a random software won't happen here, especially not security relevant server settings - max_input_vars has a good reason

@shucon

This comment has been minimized.

Contributor

shucon commented Feb 10, 2018

@thelounge-zz thanks for your suggestion , but I'm seeking help to fix the bug in the code itself.

@ibennetch ibennetch modified the milestones: 4.7.8, 4.7.9 Feb 20, 2018

@thelounge-zz

This comment has been minimized.

thelounge-zz commented Feb 20, 2018

congratulations - 4.7.8 is still broken - well done for point releases

Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
phpMyAdmin - Error

Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.

@HLeithner

This comment has been minimized.

HLeithner commented Feb 20, 2018

Awesome the second security release I can't use because phpmyadmin doesn't work anymore.

@cjchagnon

This comment has been minimized.

cjchagnon commented Feb 20, 2018

I want to comment with something productive, but can't think of much to say other than to echo the concern that this was moved back from 4.7.8 to 4.7.9;

This bug has made the tool very difficult to work with on tables that have lots of attributes, or lots of rows.

My current workaround for my end-users is to have them use pagination, but, with this issue, table search / filtering also becomes unusable. So a quick turnaround on this would be much appreciated.

@skyale

This comment has been minimized.

skyale commented Feb 21, 2018

I see that 4.7.9 is in "No due date" status, while 4.8.0 is "Due by March 21, 2018". So we'll don't see 4.7.9, and will jump directly to 4.8.0?

Thank you for your work, we really appreciate it.

@jebsolutions

This comment has been minimized.

jebsolutions commented Feb 21, 2018

Mentally insert some rants about 99% useless POST data. :)

Here's a fun experiment:

  • In firefox...launch phpmyadmin
  • Browse a table that fails on edit
  • Right-click on a row in the table and select "Inspect Element". It will open the dev tools.
  • Find the parent for this row of data....right click and delete node.
  • Go nuts and delete all the tr's in the table showing the database rows except one.

So now you have a browse screen with only one row of data. What happens when you click edit?

Magically it all works. So all that data isn't needed.

The proper fix was already mentioned...split into sub-forms and/or build a proper POST with just the needed data.

However...consider this as a possible easy hack:

Before you post the "form" have the javascript delete all the rows in the table above and below the one row of data that was actually clicked (like our manual node delete experiment). This will remove the useless data that isn't needed anyway.

Jquery details left to those who enjoy that stuff.

@boomsya

This comment has been minimized.

boomsya commented Feb 28, 2018

in phpMyAdmin-4.8+snapshot all OK. Thanks.
Waiting stable version

@nijel

This comment has been minimized.

Member

nijel commented Mar 1, 2018

Should be fixed in QA_4_7 as well thanks to #14036.

@nijel nijel closed this Mar 1, 2018

ibennetch added a commit that referenced this issue Mar 1, 2018

More ChangeLog entries related to c21a9cf; issues #13927 and #13887
Signed-off-by: Isaac Bennetch <bennetch@gmail.com>
@skyale

This comment has been minimized.

skyale commented Mar 6, 2018

Hi everyone, do you test 4.7.9?

Is it resolved error message: "Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini" ?

@HLeithner

This comment has been minimized.

HLeithner commented Mar 6, 2018

yes seams to work now.

@jebsolutions

This comment has been minimized.

jebsolutions commented Mar 8, 2018

Thank you! :)

So far 4.7.9 looks good! 👍

@skyale

This comment has been minimized.

skyale commented Mar 11, 2018

Great! Everything works!

@llamafilm

This comment has been minimized.

llamafilm commented May 12, 2018

Now that this is fixed, how many input variables are there — would it be equal to the number of rows? Or because of the grid edit, would it be rows * columns? I'm just trying to figure out how large max_input_vars really needs to be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment