Skip to content
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
Assignees
Labels
Milestone

Comments

@thelounge-zz
Copy link

@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
Copy link

@jeff-kilbride 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
Copy link
Author

@thelounge-zz 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

@thelounge-zz
Copy link
Author

@thelounge-zz 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
Copy link

@jeff-kilbride 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
Copy link
Author

@thelounge-zz 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
Copy link

@HLeithner 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
Copy link
Member

@nijel 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
Copy link
Author

@thelounge-zz 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
Copy link
Member

@nijel 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
Copy link
Author

@thelounge-zz 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
Copy link

@HLeithner HLeithner commented Jan 8, 2018

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

@nijel
Copy link
Member

@nijel 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
Copy link
Author

@thelounge-zz 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
Copy link
Member

@nijel 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
Copy link
Member

@ibennetch 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
Copy link

@CyberCr33p CyberCr33p commented Feb 8, 2018

Any news about this issue?

@shucon
Copy link
Contributor

@shucon 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
Copy link
Author

@thelounge-zz 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
Copy link
Contributor

@shucon 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
Copy link
Author

@thelounge-zz 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
Copy link

@HLeithner HLeithner commented Feb 20, 2018

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

@cjchagnon
Copy link

@cjchagnon 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
Copy link

@skyale 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
Copy link

@jebsolutions 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
Copy link

@boomsya boomsya commented Feb 28, 2018

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

@nijel
Copy link
Member

@nijel 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
Signed-off-by: Isaac Bennetch <bennetch@gmail.com>
@skyale
Copy link

@skyale 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
Copy link

@HLeithner HLeithner commented Mar 6, 2018

yes seams to work now.

@jebsolutions
Copy link

@jebsolutions jebsolutions commented Mar 8, 2018

Thank you! :)

So far 4.7.9 looks good! 👍

@skyale
Copy link

@skyale skyale commented Mar 11, 2018

Great! Everything works!

@llamafilm
Copy link

@llamafilm 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.