THank all of you for your help. I think I got this thing licked.
On Wed, Apr 24, 2013 at 7:14 PM, Ken Kixmoeller wrote:
> Thank you very much, Jim ---
>
>
> On Wed, Apr 24, 2013 at 5:34 PM, Jim Lucas wrote:
>
>> On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:
>>
>>> Thanks, Jim ---
>>>
>>> Is th
Thank you very much, Jim ---
On Wed, Apr 24, 2013 at 5:34 PM, Jim Lucas wrote:
> On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:
>
>> Thanks, Jim ---
>>
>> Is this different from the "max_input_vars" discussion above? (from David
>> OBrien)
>>
>
> yes. For example...
>
> php.ini:[suhosin]
> php.
On 04/24/2013 03:24 PM, Ken Kixmoeller wrote:
Thanks, Jim ---
Is this different from the "max_input_vars" discussion above? (from David
OBrien)
yes. For example...
php.ini:[suhosin]
php.ini:;suhosin.log.syslog =
php.ini:;suhosin.log.syslog.facility =
php.ini:;suhosin.log.syslog.priority =
ph
Thanks, Jim ---
Is this different from the "max_input_vars" discussion above? (from David
OBrien)
Ken
On Wed, Apr 24, 2013 at 5:06 PM, Jim Lucas wrote:
> On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:
>
>> Thanks so much. Yes, we found that because PHP threw an error that said
>> that explicit
On 04/24/2013 02:40 PM, Ken Kixmoeller wrote:
Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.
At first, that appeared to fix it (on the development machine).
Thanks so much. Yes, we found that because PHP threw an error that said
that explicitly. A bit of research led us to add a line to php.ini to set
the "max_input_vars" to a higher level.
At first, that appeared to fix it (on the development machine). The
appearance is wrong; it is still broken. No
On Wed, Apr 24, 2013 at 5:14 PM, David OBrien wrote:
> On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller wrote:
>
>> Hey - --
>>
>> I have a huge screen -- to make it simple for the user, it does 100s of
>> calls to MySQL and has 1,000s (literally) of POST variables.
>>
>> We have done extensive re
>From the link: "The php_register_variable_ex function in php_variables.c in
PHP 5.3.9 allows remote attackers to execute arbitrary code via a request
containing a large number of variables, related to improper handling of
array variables. NOTE: this vulnerability exists because of an incorrect
fix
On Wed, Apr 24, 2013 at 5:09 PM, Ken Kixmoeller wrote:
> Hey - --
>
> I have a huge screen -- to make it simple for the user, it does 100s of
> calls to MySQL and has 1,000s (literally) of POST variables.
>
> We have done extensive research and see that upgrading from php 5.1.6-27 to
> 5.1.6-39 i
Hey - --
I have a huge screen -- to make it simple for the user, it does 100s of
calls to MySQL and has 1,000s (literally) of POST variables.
We have done extensive research and see that upgrading from php 5.1.6-27 to
5.1.6-39 is the thing that caused it to break. All other issues (Apache,
PHP an
10 matches
Mail list logo
