Marc Delisle a écrit :
Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:56 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-08-07 08:20, Tyron Madlener a écrit :
On Sun, Aug 7, 2011 at 3:01 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-08-07 07:39, Marc Delisle a écrit :
Le 2011-08-07 07:31, Tyron Madlener a écrit : > On Sun, Aug 7, 2011 at 2:06 PM, Marc Delisle marc@infomarc.info wrote: >> Le 2011-08-06 07:59, Madhura Jayaratne a écrit : >>> Hi all, >>> >>> While attending to a bug [1], I came across the following. >>> Suhosin imposes a limit of 512 on the length of the variable that can be >>> passed via a GET [2]. This is often problematic as in PMA we encounter long >>> parameters (long sql queries, where clauses when no unique key is there >>> etc). Due to the same problem [3] $cfg['LinkLengthLimit'] configuration was >>> lowered to more stricter 1000 from 2000, which is more acceptable. >>> >>> In this particular bug the problem is that, though the URL length is under >>> 1000, one parameter, 'sql_query', violates the Suhosin limit. What >>> should be our stand on this. Should we adhere to Suhosin default values? >>> >>> In 3.5 we have a possible solution for this [4] and we can still lower >>> $cfg['LinkLengthLimit'] value without losing the look and feel. However this >>> needs to have JS enabled and I'm not sure whether we want to impose that >>> condition for the 3.4 series. >> Madhura, >> see Documentation.html, FAQ 1.38. You might want to add a suggestion >> there about suhosin.get.max_value_length. >> >> As you can deduce from this FAQ entry, it was not our intention to adapt >> to Suhosin's limits. > Would there be any problem in using min($cfg['LinkLengthLimit'], > [suhoins max length]) for pma? You might have a good start of solution, but $cfg['LinkLengthLimit'] is for the total length of the link, whereas suhosin.get.max_value_length is per parameter and we have more than one parameter in those links.
Also, looking at FAQ 1.38, many Suhosin parameters require tuning for phpMyadmin; this is why phpMyAdmin emits (by default) a warning on its main page about Suhosin, pointing to this FAQ entry.
If someone disabled the warning, it's their choice.
Seeing that many linux distributions like debian ship php with suhosin per default many users must be affected by issues with suhosin. And suhosin is not just your average addon, it adds important security enhancements to php. Disabling it can have severe consequences.
Marking that bug entry as "won't fix" is an indirect statement that we either don't care about the users with php+suhosin or that we don't care about the users security (forcing them to disable suhosin).
Having phpMyAdmin working with suhosin is a completely valid feature request and should be handled as such, in my opinion. Not saying that we have to implement that feature now, but the possibilities definitely should be kept open.
Continuing Tyron's idea, here is a possible fix. PMA_linkOrButton() currently checks the whole URL length and decides to generate a link or form based on this.
In the form generation logic, it breaks the URL with parse_url(). This parse_url could occur earlier in the function, enabling a verification of the length of each parameter value against suhosin.get.max_value_length and forcing to use the "form" logic as soon as one of the values will exceed the limit.
Anyone with a Suhosin-enabled server wants to try this?
Attached patch should implement this behavior, though not tested yet.
Thanks. I have pushed your patch to origin/master as I don't have Suhosin here to test; so we'll test on the demo server.
Tested, fix confirmed.