0

i've got csrf integrated throughout an entire app. no problems anywhere until today when working with a client to show them around. the area in question allows a user to search, select a subset (or all) of the items represented, and then move forward to do some data work with them.

it works totally fine until you hit ~70 records. if you've selected > 70 of the items and click the button to proceed then the function being called throws back the CSRF error The action you have requested is not allowed.

if I remove items to get below 70 then it works again. if I have the csrf token printed to the console it still shows up accurately when attempting to submit the 70+ items array.

i'm in Codeigniter using jQuery.

thanks for any input!

best,

John Blythe
  • 603
  • 1
  • 7
  • 21
  • 1
    Possibly related to the max post values you've configured to allow (see http://stackoverflow.com/questions/9505192/php-post-limited-to-1000-variables), 70 records (with possibly multiple fields per record) can quite add up. – Wrikken Oct 16 '13 at 22:50
  • Ahhhh hadn't even considered that. Great idea. Will try it out and get back to you! – John Blythe Oct 17 '13 at 00:11
  • so i ran `phpinfo();` to see ensure I was editing the right `php.ini` file. got the following info in the output: `Configuration File (php.ini) Path /Applications/MAMP/bin/php/php5.4.4/conf` and `Loaded Configuration File /Library/Application Support/appsolute/MAMP PRO/conf/php.ini`. I then proceeded to edit *both* of them to make certain that the `max_input_vars` would be updated to 10000 instead of 1000. `phpinfo()` is still showing that the default value of 1000 is what is being read/seen. I stopped and restarted Apache, too, in case there was issue there. any ideas on why it isn't taking? – John Blythe Oct 17 '13 at 12:49
  • 1
    Do you have an _"Scan this dir for additional .ini files"_ or _"Additional .ini files parsed" _? Might be there. Also, grep recursively in your webserver config and .htaccess files, it's `PHP_INI_PERDIR`, so configurable there. – Wrikken Oct 17 '13 at 13:48
  • good and bad news. bad: still no luck locally. i'll try the above later this evening when i have a chance to toy a bit. good news: was able to change it on production server and voila! can you convert your comment to an answer so i can mark it as correct? thanks a bunch! will post re: local deal tonight or tomorrow, too. would love to figure out / know more about that situation as well – John Blythe Oct 17 '13 at 21:23
  • 2
    Possible duplicate of [400 Bad Request - request header or cookie too large](http://stackoverflow.com/questions/17524396/400-bad-request-request-header-or-cookie-too-large) – Paul Sweatte Nov 22 '15 at 04:48
  • @PaulSweatte How are those duplicates? – Madara's Ghost Nov 22 '15 at 08:50

1 Answers1

0

Use the following process to troubleshoot:

  • Check how the data is being stored in the session
  • If the data is being stored in the session, check the cookie of different requests
  • If the cookie size changes based on the data set, it may be reaching the limit
  • The limit varies by browser, so compare across browsers

References

Community
  • 1
  • 1
Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265