php-general Digest 5 Aug 2008 02:00:29 -0000 Issue 5607
Topics (messages 277667 through 277690):
Re: SoapClient and arrays
277667 by: Aschwin Wesselius
Not found regex
277668 by: Manoj Singh
277669 by: Wei, Alice J.
277670 by: Yeti
277671 by: Manoj Singh
277672 by: Shawn McKenzie
277681 by: Boyd, Todd M.
277682 by: Shawn McKenzie
Re: PDO prepared statements and LIKE escaping
277673 by: Larry Garfield
277675 by: Per Jessen
277676 by: Andrew Ballard
277678 by: Larry Garfield
277684 by: Boyd, Todd M.
277685 by: Adam Richardson
277687 by: Larry Garfield
277688 by: Adam Richardson
277689 by: Asher Snyder
mail script not working
277674 by: Richard Kurth
277677 by: Per Jessen
Re: uploading big files with PHP
277679 by: Daniel Brown
Re: E-Shop system
277680 by: Micah Gersten
Re: Since APC is no longer supported on Windows, can anyone else make
php_apc.dll for the newest 5.2.6 non-thread-safe?
277683 by: steve
Re: PHP Memory Management
277686 by: Waynn Lue
PHP querying mysql db for data limited to the last month
277690 by: Vinny Gullotta
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Marten Lehmann wrote:
Hello,
I'm calling a webservice that is described by a WSDL-URL using the
PHP-builtin Soap client. This works fine in general. But although the
response is received correct, the variable type is wrong.
According to the WSDL file, the response is defined like this:
<s:element name="SaveResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="SaveResult"
type="s:boolean" />
<s:element minOccurs="0" maxOccurs="1" name="key"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="messages"
type="tns:ArrayOfMessage" />
</s:sequence>
</s:complexType>
</s:element>
This pice of code:
print gettype($response). "\n";
var_dump($response);
print $response["key"]. "\n";
returns this:
object
object(stdClass)#2 (3) {
["SaveResult"]=>
bool(true)
["key"]=>
string(52) "FGLHRQXVDQJXQAWBCGJWNCQKTOYFGGMJSHYQELJPSABDGUNZWBEA"
["messages"]=>
object(stdClass)#3 (0) {
}
}
Fatal error: Cannot use object of type stdClass as array in
/whatever/soap.php on line 26
You can see the structure of an associative array. But PHP doesn't
treat it as an array. Now with the following code, it works fine:
settype($response, "array");
print gettype($response). "\n";
var_dump($response);
print $response["key"]. "\n";
This returns:
array
array(3) {
["SaveResult"]=>
bool(true)
["key"]=>
string(50) "FGLHRQXWDWKHQPWRDCKSNYRGUKZBHCNFSXZHENMTVKEHJZQPYZ"
["messages"]=>
object(stdClass)#3 (0) {
}
}
FGLHRQXWDWKHQPWRDCKSNYRGUKZBHCNFSXZHENMTVKEHJZQPYZ
But it seems a bit unhandy and a workaround, if I have to the
settype() thing each time I call a webservice. Is there a simpler way?
Regards
Marten
Hi,
What about $response->key ??? What does that give? It seems to me, that
$response->key will be a public property of the stdClass?
--
Aschwin Wesselius
/'What you would like to be done to you, do that to the other....'/
--- End Message ---
--- Begin Message ---
Hello All,
I have to create the regular expression to allow all the file extensions
except the specified extension.
Suppose I want to allow extensions with php, so the regex is: ^.+\.php$
But here i need the regex which allows all the extensions except php.
I will appreciate any help.
Best Regards,
Manoj Kumar Singh
--- End Message ---
--- Begin Message ---
________________
From: Manoj Singh [EMAIL PROTECTED]
Sent: Monday, August 04, 2008 10:44 AM
To: [EMAIL PROTECTED]
Subject: [PHP] Not found regex
Hello All,
I have to create the regular expression to allow all the file extensions
except the specified extension.
Suppose I want to allow extensions with php, so the regex is: ^.+\.php$
But here i need the regex which allows all the extensions except php.
Maybe you can do a if statement that says if it maches the regex you provided
above, then print the error? If else, do whatever it is supposed to do?
Hope this helps.
I will appreciate any help.
Best Regards,
Manoj Kumar Singh
======================================================
Alice Wei
MIS 2009
School of Library and Information Science
Indiana University Bloomington
[EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
<?php
$file = '/example/hello.php';
$info = pathinfo($file);
$not_allowed = array('php', 'pt', 'exe');
if (!in_array(strtolower($info['extension']), $not_allowed)) {
// do something
}
// why use a regex?
?>
On Mon, Aug 4, 2008 at 4:44 PM, Manoj Singh <[EMAIL PROTECTED]> wrote:
> Hello All,
> I have to create the regular expression to allow all the file extensions
> except the specified extension.
>
> Suppose I want to allow extensions with php, so the regex is: ^.+\.php$
>
> But here i need the regex which allows all the extensions except php.
>
>
> I will appreciate any help.
>
> Best Regards,
> Manoj Kumar Singh
>
--- End Message ---
--- Begin Message ---
Hi All,
Thanks for your replies.
Actually i am placing this regex in .htaccess file.
Here i have to redirect all the request to https if it is not for ogg file.
The complete code is:
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^.+\.ogg$ //Need some tweaking here. I know this
code works just opposite. Need your help here.
RewriteRule .* https://%{HTTP_HOST}/ [L]
Hope this helps to understand the problem.
Best Regards
Manoj Singh
On Mon, Aug 4, 2008 at 8:24 PM, Yeti <[EMAIL PROTECTED]> wrote:
> <?php
> $file = '/example/hello.php';
> $info = pathinfo($file);
> $not_allowed = array('php', 'pt', 'exe');
> if (!in_array(strtolower($info['extension']), $not_allowed)) {
> // do something
> }
>
> // why use a regex?
> ?>
> On Mon, Aug 4, 2008 at 4:44 PM, Manoj Singh <[EMAIL PROTECTED]>
> wrote:
> > Hello All,
> > I have to create the regular expression to allow all the file extensions
> > except the specified extension.
> >
> > Suppose I want to allow extensions with php, so the regex is: ^.+\.php$
> >
> > But here i need the regex which allows all the extensions except php.
> >
> >
> > I will appreciate any help.
> >
> > Best Regards,
> > Manoj Kumar Singh
> >
>
--- End Message ---
--- Begin Message ---
Manoj Singh wrote:
Hi All,
Thanks for your replies.
Actually i am placing this regex in .htaccess file.
Here i have to redirect all the request to https if it is not for ogg file.
The complete code is:
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^.+\.ogg$ //Need some tweaking here. I know this
code works just opposite. Need your help here.
RewriteRule .* https://%{HTTP_HOST}/ [L]
Hope this helps to understand the problem.
Best Regards
Manoj Singh
It will be part of the condition syntax not the regex:
RewriteCond %{REQUEST_URI} !^.+\.ogg$
Maybe better as (not tested):
RewriteCond %{REQUEST_URI} !^[^\.]*\.ogg$
-Shawn
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Shawn McKenzie [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 04, 2008 10:33 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP] Not found regex
>
> Manoj Singh wrote:
> > Hi All,
> > Thanks for your replies.
> >
> > Actually i am placing this regex in .htaccess file.
> > Here i have to redirect all the request to https if it is not for
ogg
> file.
> >
> > The complete code is:
> > RewriteCond %{HTTPS} off
> > RewriteCond %{REQUEST_URI} ^.+\.ogg$ //Need some tweaking here. I
> know this
> > code works just opposite. Need your help here.
> > RewriteRule .* https://%{HTTP_HOST}/ [L]
> >
> > Hope this helps to understand the problem.
> >
> > Best Regards
> > Manoj Singh
>
> It will be part of the condition syntax not the regex:
>
> RewriteCond %{REQUEST_URI} !^.+\.ogg$
>
> Maybe better as (not tested):
>
> RewriteCond %{REQUEST_URI} !^[^\.]*\.ogg$
I'm pretty sure that a "." inside of a character set (the square
brackets []) doesn't need to be slashed. You're looking for "not a
backslash or a period" in that character set.
And btw... if you don't need to have the entire pathname returned (but
only whether or not it matches your condition), then you can trim the
fat off your regex and just use:
!\.ogg$
Todd Boyd
Web Programmer
--- End Message ---
--- Begin Message ---
Boyd, Todd M. wrote:
-----Original Message-----
From: Shawn McKenzie [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 10:33 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP] Not found regex
Manoj Singh wrote:
Hi All,
Thanks for your replies.
Actually i am placing this regex in .htaccess file.
Here i have to redirect all the request to https if it is not for
ogg
file.
The complete code is:
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^.+\.ogg$ //Need some tweaking here. I
know this
code works just opposite. Need your help here.
RewriteRule .* https://%{HTTP_HOST}/ [L]
Hope this helps to understand the problem.
Best Regards
Manoj Singh
It will be part of the condition syntax not the regex:
RewriteCond %{REQUEST_URI} !^.+\.ogg$
Maybe better as (not tested):
RewriteCond %{REQUEST_URI} !^[^\.]*\.ogg$
I'm pretty sure that a "." inside of a character set (the square
brackets []) doesn't need to be slashed. You're looking for "not a
backslash or a period" in that character set.
And btw... if you don't need to have the entire pathname returned (but
only whether or not it matches your condition), then you can trim the
fat off your regex and just use:
!\.ogg$
Todd Boyd
Web Programmer
Yes, the important part being !
-Shawn
--- End Message ---
--- Begin Message ---
On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
> Larry Garfield wrote:
>
>> IIRC, the way in SQL to circumvent that is to convert "100%" into
>> "100%%". However, that does rather defeat the purpose of a prepared
>> statement if I have to do my own escaping anyway, does it not?=20
>
> Depends on what you perceive the purpose of the prepared statement to
> be :-) In this context, I tend to think of performance only. Which is=
>
> generally why I can't be bothered with prepared statements in php.=20
Actually in most cases in PHP you don't get much performance. What you do get
is added security, because prepared statements are cleaner than cleaner and
more reliable than string escaping. Of course, then we run into the % problem
above.
--Larry Garfield
--- End Message ---
--- Begin Message ---
Larry Garfield wrote:
> Actually in most cases in PHP you don't get much performance.
Exactly.
> What you do get is added security, because prepared statements are
> cleaner than cleaner and more reliable than string escaping. Of
> course, then we run into the % problem above.
I don't really buy that - the string escaping is just a call to a mysql
API, surely that's perfectly reliable.
How do you see prepared statements being cleaner and more reliable?
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield <[EMAIL PROTECTED]> wrote:
>
> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
>> Larry Garfield wrote:
>>
>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
>>> "100%%". However, that does rather defeat the purpose of a prepared
>>> statement if I have to do my own escaping anyway, does it not?=20
>>
>> Depends on what you perceive the purpose of the prepared statement to
>> be :-) In this context, I tend to think of performance only. Which is=
>>
>> generally why I can't be bothered with prepared statements in php.=20
>
> Actually in most cases in PHP you don't get much performance. What you do
> get is added security, because prepared statements are cleaner than cleaner
> and more reliable than string escaping. Of course, then we run into the %
> problem above.
>
> --Larry Garfield
True. I wish PDO would add an option of creating a parameterized query
WITHOUT preparing it, at least for SQL Server. Why? There is overhead
to creating the statement that way. I prefer using the "prepared
statement" method as it decreases the exposure and risk to SQL
injection.
I'd like to see an option like the Microsoft ADO library so that I can
prepare the statement if I will be running it several times with
different parameter values each time, or choose not to incur the
overhead if I'm only going to run a statement once.
Andrew
--- End Message ---
--- Begin Message ---
On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield <[EMAIL PROTECTED]>
> wrote:
>>
>> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]> wrote:
>>> Larry Garfield wrote:
>>>
>>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
>>>> "100%%". However, that does rather defeat the purpose of a prepared
>>>> statement if I have to do my own escaping anyway, does it not?=20
>>>
>>> Depends on what you perceive the purpose of the prepared statement to
>>> be :-) In this context, I tend to think of performance only. Which
> is=
>>>
>>> generally why I can't be bothered with prepared statements in php.=20
>>
>> Actually in most cases in PHP you don't get much performance. What you
> do get is added security, because prepared statements are cleaner than
> cleaner and more reliable than string escaping. Of course, then we run
> into the % problem above.
>>
>> --Larry Garfield
>
> True. I wish PDO would add an option of creating a parameterized query
> WITHOUT preparing it, at least for SQL Server. Why? There is overhead
> to creating the statement that way. I prefer using the "prepared
> statement" method as it decreases the exposure and risk to SQL
> injection.
>
> I'd like to see an option like the Microsoft ADO library so that I can
> prepare the statement if I will be running it several times with
> different parameter values each time, or choose not to incur the
> overhead if I'm only going to run a statement once.
I've solved that at least for the given page request with a caching layer on
top of PDO. It caches and reuses the statement objects. The problem is the
issue with LIKE as described above, which I still haven't figured out yet.
--Larry Garfield
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Andrew Ballard [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 04, 2008 10:49 AM
> To: PHP General list
> Subject: Re: [PHP] PDO prepared statements and LIKE escaping
>
> On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield
> <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
> wrote:
> >> Larry Garfield wrote:
> >>
> >>> IIRC, the way in SQL to circumvent that is to convert "100%" into
> >>> "100%%". However, that does rather defeat the purpose of a prepared
> >>> statement if I have to do my own escaping anyway, does it not?=20
> >>
> >> Depends on what you perceive the purpose of the prepared statement
> to
> >> be :-) In this context, I tend to think of performance only. Which
> is=
> >>
> >> generally why I can't be bothered with prepared statements in
> php.=20
> >
> > Actually in most cases in PHP you don't get much performance. What
> you do get is added security, because prepared statements are cleaner
> than cleaner and more reliable than string escaping. Of course, then
> we run into the % problem above.
> >
> > --Larry Garfield
>
> True. I wish PDO would add an option of creating a parameterized query
> WITHOUT preparing it, at least for SQL Server. Why? There is overhead
> to creating the statement that way. I prefer using the "prepared
> statement" method as it decreases the exposure and risk to SQL
> injection.
>
> I'd like to see an option like the Microsoft ADO library so that I can
> prepare the statement if I will be running it several times with
> different parameter values each time, or choose not to incur the
> overhead if I'm only going to run a statement once.
I believe that (and don't quote me on this) newer versions of SQL Server are
setup to where EVERYTHING is "compiled", even ordinary statements. A lot of the
reading I have done about execution paths of SQL Server queries lead me to
believe that they're all handled in a generic manner by default.
'Course... I could be wrong, or perhaps I was reading about special case
scenarios.
Todd Boyd
Web Programmer
--- End Message ---
--- Begin Message ---
Larry,
I agree that having to escape values in a stored procedure does run counter
to expectations. It's likely other developers have the potential for
short-circuiting their LIKE conditions without realizing it.
I've dealt with this issue, too, and haven't been especially pleased with
any of the solutions I've undertaken. Recently, I've been avoiding LIKE
conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential
for unescaped wildcards.
Adam
On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield <[EMAIL PROTECTED]>wrote:
>
> On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
> wrote:
> >>> Larry Garfield wrote:
> >>>
> >>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
> >>>> "100%%". However, that does rather defeat the purpose of a prepared
> >>>> statement if I have to do my own escaping anyway, does it not?=20
> >>>
> >>> Depends on what you perceive the purpose of the prepared statement to
> >>> be :-) In this context, I tend to think of performance only. Which
> > is=
> >>>
> >>> generally why I can't be bothered with prepared statements in php.=20
> >>
> >> Actually in most cases in PHP you don't get much performance. What you
> > do get is added security, because prepared statements are cleaner than
> > cleaner and more reliable than string escaping. Of course, then we run
> > into the % problem above.
> >>
> >> --Larry Garfield
> >
> > True. I wish PDO would add an option of creating a parameterized query
> > WITHOUT preparing it, at least for SQL Server. Why? There is overhead
> > to creating the statement that way. I prefer using the "prepared
> > statement" method as it decreases the exposure and risk to SQL
> > injection.
> >
> > I'd like to see an option like the Microsoft ADO library so that I can
> > prepare the statement if I will be running it several times with
> > different parameter values each time, or choose not to incur the
> > overhead if I'm only going to run a statement once.
>
> I've solved that at least for the given page request with a caching layer
> on top of PDO. It caches and reuses the statement objects. The problem is
> the issue with LIKE as described above, which I still haven't figured out
> yet.
>
> --Larry Garfield
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hm. So your solution is "don't use LIKE"? I can't say I'm wild about that. :-/
--Larry Garfield
On Mon, 4 Aug 2008 15:49:52 -0400, "Adam Richardson" <[EMAIL PROTECTED]> wrote:
> Larry,
>
> I agree that having to escape values in a stored procedure does run
> counter
> to expectations. It's likely other developers have the potential for
> short-circuiting their LIKE conditions without realizing it.
>
> I've dealt with this issue, too, and haven't been especially pleased with
> any of the solutions I've undertaken. Recently, I've been avoiding LIKE
> conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the potential
> for unescaped wildcards.
>
> Adam
>
> On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield
> <[EMAIL PROTECTED]>wrote:
>
>>
>> On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]>
>> wrote:
>> > On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield
> <[EMAIL PROTECTED]>
>> > wrote:
>> >>
>> >> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
>> wrote:
>> >>> Larry Garfield wrote:
>> >>>
>> >>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
>> >>>> "100%%". However, that does rather defeat the purpose of a prepared
>> >>>> statement if I have to do my own escaping anyway, does it not?=20
>> >>>
>> >>> Depends on what you perceive the purpose of the prepared statement
> to
>> >>> be :-) In this context, I tend to think of performance only. Which
>> > is=
>> >>>
>> >>> generally why I can't be bothered with prepared statements in
> php.=20
>> >>
>> >> Actually in most cases in PHP you don't get much performance. What
> you
>> > do get is added security, because prepared statements are cleaner than
>> > cleaner and more reliable than string escaping. Of course, then we
> run
>> > into the % problem above.
--- End Message ---
--- Begin Message ---
Like I said, I'm not 'especially pleased' with any idea up until now. I'm
certainly open to any other ideas.
Adam
On Mon, Aug 4, 2008 at 6:57 PM, Larry Garfield <[EMAIL PROTECTED]>wrote:
>
> Hm. So your solution is "don't use LIKE"? I can't say I'm wild about
> that. :-/
>
> --Larry Garfield
>
> On Mon, 4 Aug 2008 15:49:52 -0400, "Adam Richardson" <[EMAIL PROTECTED]>
> wrote:
> > Larry,
> >
> > I agree that having to escape values in a stored procedure does run
> > counter
> > to expectations. It's likely other developers have the potential for
> > short-circuiting their LIKE conditions without realizing it.
> >
> > I've dealt with this issue, too, and haven't been especially pleased with
> > any of the solutions I've undertaken. Recently, I've been avoiding LIKE
> > conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the
> potential
> > for unescaped wildcards.
> >
> > Adam
> >
> > On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield
> > <[EMAIL PROTECTED]>wrote:
> >
> >>
> >> On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]
> >
> >> wrote:
> >> > On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield
> > <[EMAIL PROTECTED]>
> >> > wrote:
> >> >>
> >> >> On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
> >> wrote:
> >> >>> Larry Garfield wrote:
> >> >>>
> >> >>>> IIRC, the way in SQL to circumvent that is to convert "100%" into
> >> >>>> "100%%". However, that does rather defeat the purpose of a prepared
> >> >>>> statement if I have to do my own escaping anyway, does it not?=20
> >> >>>
> >> >>> Depends on what you perceive the purpose of the prepared statement
> > to
> >> >>> be :-) In this context, I tend to think of performance only. Which
> >> > is=
> >> >>>
> >> >>> generally why I can't be bothered with prepared statements in
> > php.=20
> >> >>
> >> >> Actually in most cases in PHP you don't get much performance. What
> > you
> >> > do get is added security, because prepared statements are cleaner than
> >> > cleaner and more reliable than string escaping. Of course, then we
> > run
> >> > into the % problem above.
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Depending on what database you're using you might be able to use LIKE
while maintaining security. For instance PostgreSQL has the functions
quote_ident(), and quote_literal() which would allow you to use LIKE
since these functions would automatically make the string suitable for
comparison.
So for instance in a stored procedure in PostgreSQL you could do:
SELECT * FROM sometable WHERE quote_ident(column) LIKE quote_ident($1);
Note that in the above line $1 would be the first parameter of the
stored procedure.
-Asher
Adam Richardson wrote:
Like I said, I'm not 'especially pleased' with any idea up until now. I'm
certainly open to any other ideas.
Adam
On Mon, Aug 4, 2008 at 6:57 PM, Larry Garfield <[EMAIL PROTECTED]>wrote:
Hm. So your solution is "don't use LIKE"? I can't say I'm wild about
that. :-/
--Larry Garfield
On Mon, 4 Aug 2008 15:49:52 -0400, "Adam Richardson" <[EMAIL PROTECTED]>
wrote:
Larry,
I agree that having to escape values in a stored procedure does run
counter
to expectations. It's likely other developers have the potential for
short-circuiting their LIKE conditions without realizing it.
I've dealt with this issue, too, and haven't been especially pleased with
any of the solutions I've undertaken. Recently, I've been avoiding LIKE
conditions and using INSTR, LOCATE, CHARINDEX, etc. to avoid the
potential
for unescaped wildcards.
Adam
On Mon, Aug 4, 2008 at 12:33 PM, Larry Garfield
<[EMAIL PROTECTED]>wrote:
On Mon, 4 Aug 2008 11:48:39 -0400, "Andrew Ballard" <[EMAIL PROTECTED]
wrote:
On Mon, Aug 4, 2008 at 11:35 AM, Larry Garfield
<[EMAIL PROTECTED]>
wrote:
On Mon, 04 Aug 2008 08:33:44 +0200, Per Jessen <[EMAIL PROTECTED]>
wrote:
Larry Garfield wrote:
IIRC, the way in SQL to circumvent that is to convert "100%" into
"100%%". However, that does rather defeat the purpose of a prepared
statement if I have to do my own escaping anyway, does it not?=20
Depends on what you perceive the purpose of the prepared statement
to
be :-) In this context, I tend to think of performance only. Which
is=
generally why I can't be bothered with prepared statements in
php.=20
Actually in most cases in PHP you don't get much performance. What
you
do get is added security, because prepared statements are cleaner than
cleaner and more reliable than string escaping. Of course, then we
run
into the % problem above.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
I have been trying to get this mail script to send an html message and
it just sends the html in plain text with all the html code showing.
Could somebody tell my way this will not work. When it does send it
takes a long time to go through but when I send a plan text message it
goes through right away
$plain_text =
"$firstname $lastname has just accesed your web site.
They went there at $today.
It would be a good time to contact them.
$firstname $lastname Phone number is $phonenumber.
Log in at http://domain.com/login.php";;
$hmessage = "<html>
<head>
<title></title>
</head>
<body>
<table>
<tr>
<td><h2>$firstname $lastname has just accesed your web site.<br>They
went there at <font color='#FF0000'>$today</font>.</h2></td>
</tr>
<tr>
<td><h3>It would be a good time to contact them.<br>$firstname
$lastname Phone number is $phonenumber.</h3>
<br><h3>Log in at <a
href='http://domain.com/login.php'>http://easycontactpro.com/login.php</a></h3></td>
</tr>
</table>
</body>
</html>";
$from="[EMAIL PROTECTED]";
$to="[EMAIL PROTECTED]";
$subject="test";
# Setup mime boundary
$mime_boundary = 'Multipart_Boundary_x'.md5(time()).'x';
$headers = "MIME-Version: 1.0\r\n";
$headers .= "Content-Type: multipart/alternative;
boundary=\"$mime_boundary\"\r\n";
$headers .= "Content-Transfer-Encoding: 7bit\r\n";
$body = "This is a multi-part message in mime format.\n\n";
# Add in plain text version
$body .= "--$mime_boundary\n";
$body .= "Content-Type: text/plain; charset=\"charset=us-ascii\"\n";
$body .= "Content-Transfer-Encoding: 7bit\n\n";
$body .= $plain_text;
$body .= "\n\n";
# Add in HTML version
$body .= "--$mime_boundary\n";
$body .= "Content-Type: text/html; charset=\"UTF-8\"\n";
$body .= "Content-Transfer-Encoding: 7bit\n\n";
$body .= $hmessage;
$body .= "\n\n";
# End email
$body .= "--$mime_boundary--\n"; # <-- Notice trailing --,
required to close email body for mime's
# Finish off headers
$headers .= "From: $from\r\n";
$headers .= "X-Sender-IP: $_SERVER[SERVER_ADDR]\r\n";
$headers .= 'Date: '.date('n/d/Y g:i A')."\r\n";
# Mail it out
mail($to, $subject, $body, $headers);
--- End Message ---
--- Begin Message ---
Richard Kurth wrote:
> I have been trying to get this mail script to send an html message and
> it just sends the html in plain text with all the html code showing.
> Could somebody tell my way this will not work. When it does send it
> takes a long time to go through but when I send a plan text message it
> goes through right away
To begin with, you need to use '\r\n' to end each and every line, not
just the odd one.
Once you've got that fixed, send me a test email and I'll check it out.
/Per Jessen, Zürich
--- End Message ---
--- Begin Message ---
On Mon, Aug 4, 2008 at 12:55 AM, Catalin Zamfir Alexandru | KIT
Software CAZ <[EMAIL PROTECTED]> wrote:
> What are you talking about? I've been able to upload a 4GB file without
> problem. Uploading doesn't depend on memory limit, and this has been a
> subject of debate on the PHP.net Manual (uploading files section, check it
> out).
The PHP manual is not a place for debate. That's one of the
reasons this discussion list is here.
--
</Daniel P. Brown>
Better prices on dedicated servers:
Intel 2.4GHz/60GB/512MB/2TB $49.99/mo.
Intel 3.06GHz/80GB/1GB/2TB $59.99/mo.
Dedicated servers, VPS, and hosting from $2.50/mo.
--- End Message ---
--- Begin Message ---
Alain Roger wrote:
> Hi,
>
> i'm currently analyzing an e-shop system.
> i understand how to display products and so on, however i still have some
> question marks on the following topics:
>
> 1. what is the best way for showing product image ?
> - to store them in DB or onto filesystem as simple image files ?
> - each product should have 2 images (1 small when user browser the
> catalogue, 1 huge (standard) when user wants to see how product looks like).
> Should be 1 or 2 images ? I mean should i store in DB/filesystem the
> standard file and reduce size for user browsing ?
>
I usually store the name in the DB and the image on the FS.
> 2. billing interaction
> basically i was thinking to allow users to pay via PayPal, Bank2Bank and by
> credit card.
> - What i do not understand is how can i interact with such third party
> company ?
> - for paypal: how can i redirect user to PayPal and pay to my account and
> how to get back information that he paid (and that i can send the good) ?
> - Bank transfer: how can i control it ?
> - Credit card payment: how can i be sure that when user give me his credit
> card number, my application will secure it enough ? how can i get back
> information that it's true...user paid the good and i can send him the
> product ?
>
> thanks a lot for all your feedback.
>
>
Paypal can handle itself, Bank Transfers and Credit Cards for you. They
have nice APIs.
Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com
--- End Message ---
--- Begin Message ---
Yeah, back from January. They stopping shipping APC in the PHP
downloads (specifically the PECL download for Windows). And since
pecl4win.php.net does NOT have the nts versions, it is pretty useless.
On Sat, Jul 26, 2008 at 12:22 AM, T Lensselink <[EMAIL PROTECTED]> wrote:
> steve wrote:
>> Since APC is no longer supported on Windows, I can't download it from
>> php.net. Can anyone else make php_apc.dll for the newest 5.2.6
>> non-thread-safe windows version?
>>
>> Many thanks in advance...
>>
>>
> I never heard anything about dropping support for windows.
> And on pecl4win there is still a apc dll for the 5_2 branch..
>
> http://pecl4win.php.net/ext.php/php_apc.dll
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
>
> Waynn Lue wrote:
>
>> I've been running the script below:
>>
>> <?php
>> $appIds = getLotsOfAppIds();
>> foreach ($appIds as $appId) {
>> echo "$appId\n";
>> //echo memory_get_usage() . "\n";
>> try {
>> $getBundles = getBundles($appId);
>> $numBundles = count($registeredBundles);
>> echo $numBundles . "\n";
>> continue;
>> }
>> }
>> ?>
>>
>> And I get PHP Fatal Error: Allowed Memory Size Exhausted after it runs for
>> a
>> bit. Looking at the memory usage, it's because $getBundles (an array) is
>> huge, and keeps growing. What I'm confused by is why setting it to
>> something else in the next iteration of the foreach loop doesn't free the
>> previously allocated array, since there shouldn't be any more references
>> to
>> it. I've worked around it by explicitly calling unset($getBundles), but
>> just wanted to understand why it's working the way it does.
>>
>>
> Aside from on the 1st iteration, each time getBundles() is called, it
> creates an array within its own scope. Until PHP assigns the returned array
> to $getBundles, there are two in memory. Maybe that's the problem.
>
But that means that as soon as you move to the next iteration of the foreach
loop, both arrays should still go away, right? Instead, it looks like the
memory is continuously increasing on each iteration.
>
> I don't know how you can stand naming structures or variables the same as
> functions, btw. That would drive me nuts. Where is this $registeredBundles
> coming from? Perhaps you meant:
>
> $registeredBundles = getBundles($appId);
>
Ah, my fault. Yeah, I don't usually name variables the same as functions,
but was coming up with names on the fly as I tried to shrink my script down
to a reproducible test case.
It should have been
<?php
$appIds = getLotsOfAppIds();
foreach ($appIds as $appId) {
echo "$appId\n";
//echo memory_get_usage() . "\n";
try {
$registeredBundles = getBundles($appId);
$numBundles = count($registeredBundles);
echo $numBundles . "\n";
continue;
} catch (Exception $e) {
echo "exception caught\n";
}
}
?>
and unset($registeredBundles).
--- End Message ---
--- Begin Message ---
So I have this code I'm working with (pasted below) that queries a mysql db
table called timetracking. The goal of the page is to search the db for all
data based on a certain engineer, sorted by product and it takes pre-defined
values based on actions performed, sums them based on product and display's
the percentage of time an engineer has spent on each product. Everything
works great except I need to limit the results to the last months data only,
but everything I try seems to just break it. Can anyone push me in the right
direction a little? I have tried using BETWEEN in the SELECT statement, some
while statements and if statements, and all I do is keep breaking it. If
anyone has any ideas, it would be exceptionally helpful.
Thanks in advance,
Vinny
<?php
$total = 0;
$today = date('Y-m-d h:i:s');
$monthago = date("Y-m-d h:i:s", mktime(date("h"), date("i"), date("s"),
date("m")-1, date("d"), date("Y")));
echo "Today = ", $today;
echo "<br>One Month Ago = ", $monthago, "<br>";
$query = "SELECT *, SUM(timespent) FROM timetracking WHERE engineer =
'$engineer' GROUP BY product";
$result = mysql_query($query) or die(mysql_error());
$result2 = mysql_query($query) or die(mysql_error());
echo "<center>";
while($row = mysql_fetch_array($result)){
$total = $row['SUM(timespent)'] + $total;
}
while($row = mysql_fetch_array($result2)){
$perc = $row['SUM(timespent)'] * 100 / $total;
echo "[ <font color=#1E429B size=+1>", $row[product]. " = ".
number_format($perc,2), "%</font> ]";
}
?>
--- End Message ---
