Completely different function call().
mysql_connect() - the port is part of the host.
*server*
The MySQL server. It can also include a port number. e.g. "hostname:port"
or a path to a local socket e.g. ":/path/to/socket" for the localhost.
If the PHP directive
mysql.default_hostis
undefined (de
I know - it sounds OT, but listen.
I have a form that has a "sign in " button which attempts to sent the
user to a form in a password-protected folder. In order to get there
the user must provide credentials. Once there the receiving script
simply sets a session var and does a header() back
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
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
>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: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
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 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, 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 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
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 Tue, Apr 23, 2013 at 8:04 AM, Andrew Ballard wrote:
> On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson wrote:
>> On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard wrote:
>>> The other developer in our office spent some time profiling the site with
>>> xdebug and found that an exec() call to ne
On Apr 24, 2013 9:46 PM, "tamouse mailing lists"
wrote:
>
> On Tue, Apr 23, 2013 at 8:04 AM, Andrew Ballard
wrote:
> > On Tue, Apr 23, 2013 at 2:29 AM, Adam Richardson
wrote:
> >> On Mon, Apr 22, 2013 at 10:41 PM, Andrew Ballard
wrote:
> >>> The other developer in our office spent some time pro
13 matches
Mail list logo
