php-general Digest 25 Oct 2010 11:54:27 -0000 Issue 7005
php-general Digest 25 Oct 2010 11:54:27 - Issue 7005
Topics (messages 309045 through 309052):
Re: Stripslashes redundancy question.
309045 by: Adam Richardson
Re: I need some thoughts on code duplication and separation
309046 by: Rico Secada
Re: Reminder On Mailing List Rules
309047 by: Paul M Foster
309049 by: Gary
Best practice for if (!$stmt-execute())
309048 by: Rico Secada
309050 by: Tommy Pham
309052 by: Rico Secada
Re: Interfacing with telnet using curl
309051 by: HM 2K
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
--
---BeginMessage---
On Sun, Oct 24, 2010 at 6:29 PM, Gary gp...@paulgdesigns.com wrote:
In my form processing scripts, I usually have the variable set as so:
$email = stripslashes($_POST['email']);
I have discovered that the program that I use has a pre-written function of
this:
// remove escape characters from POST array
if (get_magic_quotes_gpc()) {
function stripslashes_deep($value) {
$value = is_array($value) ? array_map('stripslashes_deep', $value) :
stripslashes($value);
return $value;
}
$_POST = array_map('stripslashes_deep', $_POST);
}
I just put this in a script that I have been using, leaving the original
stripslashes in the variable. The script still works, but is there a
problem
with redundancy, or does one cancel the other out?
Also, which do you think is a better method to use?
Thank you
Gary
__ Information from ESET Smart Security, version of virus signature
database 5560 (20101024) __
The message was checked by ESET Smart Security.
http://www.eset.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Gary,
Calling stripslashes() more than once on the same string can cause issues.
That said, I'd point out that as of PHP 5.3, the use of magic_quotes_gpc()
has been deprecated:
http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc
http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpcThis
was after many criticisms were leveled against the use of magic quotes:
http://en.wikipedia.org/wiki/Magic_quotes
So, my inclination is to turn off magic quotes if they're on by using
php.ini -OR- htaccess (if at all possible) rather than checking if they are
on and strip them if needed.
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
---End Message---
---BeginMessage---
On Thu, 21 Oct 2010 10:55:14 -0400
Paul M Foster pa...@quillandmouse.com wrote:
On Thu, Oct 21, 2010 at 04:05:50AM +0200, Rico Secada wrote:
Hi.
I am working on a small system where I am both trying to avoid code
duplication and at the same time I am trying to keep the
presentation logic separated from the application logic.
I am using sessions and are avoiding headers already sent problem
by keeping the HTML out of the application.
For example, I would like to have a common header.php file, but it
is difficult to create this since one file needs to have some
specific Javascript located in the head /head tags, but the
other files doesn't need this.
Another file needs to have a specific onload call in the body
tag, while yet another file also needs to have an onload call,
but with different attributes.
I have been looking around in other systems to see what kinds of
solutions are being used - as inspiration.
I have been thinking about the following solutions:
1. Create only ONE header.php file that contains a lot of
conditionals depending on what file is including it - the output of
HTML/Javascript changes.
I believe this would turn into a very ugly hack. Difficult to
maintain.
Not really. Here's what I do. I have a page controller which defines
variables and such, and then calls the header.php file. The page
controller will contain something like this:
$meta['jsfiles'] = 'onload.js';
The header.php will contain code like this:
?php if (!empty($meta['jsfiles'])): ?
?php include $meta['jsfiles']; ?
?php endif; ?
The page controller can also contain a variety of other settings,
like:
$meta['content'] = 'cust_add.php';
and the header.php will contain:
?php include $meta['content']; ?
This directs the proper internal content for the header.php, which is
really like a template file.
Also remember that at the bottom of the page controller, you do a like
like this:
include 'header.php';
You can change this as you like for any given page controller.
Paul
--
Paul M. Foster
Thanks Paul! It's a nice way to do it.
---End Message---
php-general Digest 26 Oct 2010 02:24:28 -0000 Issue 7006
php-general Digest 26 Oct 2010 02:24:28 - Issue 7006
Topics (messages 309053 through 309066):
Looking for an open-source project
309053 by: Mert Oztekin
309059 by: Colin Guthrie
309061 by: Ken Guest
Re: Stripslashes redundancy question.
309054 by: Bob McConnell
309055 by: Paul M Foster
309056 by: Shawn McKenzie
309057 by: Adam Richardson
Re: Possible foreach bug; seeking advice to isolate the problem
309058 by: David Harkness
Re: Model View Concepts
309060 by: J Ravi Menon
Check for existence of mail address
309062 by: webdev.blaettner.com
309063 by: Daniel P. Brown
309064 by: Jonathan Tapicer
309065 by: webdev.blaettner.com
309066 by: Sharl.Jimh.Tsin
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
--
---BeginMessage---
Hi,
I am looking for an open-source project to help and make some fun. Anyone has
suggestions?
Bu mesaj ve ekleri, mesajda g?nderildi?i belirtilen ki?i/ki?ilere ?zeldir ve
gizlidir. Size yanl??l?kla ula?m??sa l?tfen g?nderen kisiyi bilgilendiriniz ve
mesaj? sisteminizden siliniz. Mesaj ve eklerinin i?eri?i ile ilgili olarak
?irketimizin herhangi bir hukuki sorumlulu?u bulunmamaktad?r. ?irketimiz
mesaj?n ve bilgilerinin size de?i?ikli?e u?rayarak veya ge? ula?mas?ndan,
b?t?nl???n?n ve gizlili?inin korunamamas?ndan, vir?s i?ermesinden ve bilgisayar
sisteminize verebilece?i herhangi bir zarardan sorumlu tutulamaz.
This message and attachments are confidential and intended for the
individual(s) stated in this message. If you received this message in error,
please immediately notify the sender and delete it from your system. Our
company has no legal responsibility for the contents of the message and its
attachments. Our company shall have no liability for any changes or late
receiving, loss of integrity and confidentiality, viruses and any damages
caused in anyway to your computer system.
***?imdi her yerde ?ubemiz var:
http://www.anadolusigortaonline.com.tr a??ld?.
Disclaimer added by CodeTwo Exchange Rules 2007
www.codetwo.comhttp://www.codetwo.com
---End Message---
---BeginMessage---
'Twas brillig, and Mert Oztekin at 25/10/10 13:23 did gyre and gimble:
I am looking for an open-source project to help and make some fun. Anyone has
suggestions?
How about helping out Zend Framework, adding useful classes for various
Service integrations etc.?
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
---End Message---
---BeginMessage---
On Mon, Oct 25, 2010 at 7:57 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Mert Oztekin at 25/10/10 13:23 did gyre and gimble:
I am looking for an open-source project to help and make some fun. Anyone
has suggestions?
How about helping out Zend Framework, adding useful classes for various
Service integrations etc.?
Or similarly for PEAR?
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
http://blogs.linux.ie/kenguest/
---End Message---
---BeginMessage---
From: Adam Richardson
On Sun, Oct 24, 2010 at 6:29 PM, Gary gp...@paulgdesigns.com wrote:
In my form processing scripts, I usually have the variable set as so:
$email = stripslashes($_POST['email']);
I have discovered that the program that I use has a pre-written
function of
this:
// remove escape characters from POST array
if (get_magic_quotes_gpc()) {
function stripslashes_deep($value) {
$value = is_array($value) ? array_map('stripslashes_deep', $value)
:
stripslashes($value);
return $value;
}
$_POST = array_map('stripslashes_deep', $_POST);
}
I just put this in a script that I have been using, leaving the
original
stripslashes in the variable. The script still works, but is there a
problem
with redundancy, or does one cancel the other out?
Also, which do you think is a better method to use?
Calling stripslashes() more than once on the same string can cause
issues.
That said, I'd point out that as of PHP 5.3, the use of
magic_quotes_gpc()
has been deprecated:
RE: [PHP] Best practice for if (!$stmt-execute())
-Original Message-
From: Rico Secada [mailto:coolz...@it.dk]
Sent: Sunday, October 24, 2010 9:06 PM
To: php-general@lists.php.net
Subject: [PHP] Best practice for if (!$stmt-execute())
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid check and
at
the same time return some kind of valuable db error to the user and end
the
script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
Rico,
Shouldn't you consider this as what happens, while in production, should
the script fails?, whether its DB related or not. In that case, how would
you want to handle the error? Do you, or the system admin, want to be
notified one way or another of the failure? Do want to implement a backup
in case that failure happens as an 'automatic recovery' mechanism? As a
system/network admin, I go by 3 guidelines:
1) Prevent failure as much as I can (either system hardware, software
applications, hacks/exploits/vulnerabilities, etc.).
2) In the event that 1 fails, what's the recovery process? How fast can I
recover from it?
3) If 2 fails, then there's something wrong with the whole process, which I
need to expand my knowledge skillset.
In my past experiences, I haven't yet got to stage 2 because there
precautions you can take to detect when a failure is about to happen so that
stage 2 will never happens. What you need to consider is how important is
this? Is it mission critical?
Regards,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Interfacing with telnet using curl
Before I report this as a bug, can anyone provide an example of how to
interface with a telnet server using curl?
Here's what I've tried, with various results:
pre
?php
error_reporting(E_ALL);
ini_set('display_errors','On');
function curl_telnet($query,$server,$proxy=false,$timeout=10) {
if (!function_exists('curl_init')) {
user_error('curl_init() function does not exist.', E_USER_WARNING);
return false;
}
$ch = curl_init($server);
if ($proxy) {
curl_setopt($ch, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5);
curl_setopt($ch, CURLOPT_PROXY, $proxy);
}
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, $query);
$output=curl_exec($ch);
curl_close($ch);
return $output;
}
$tests=array();
$tests['rainmaker.wunderground.com:23']=\r\n\r\nx\r\n;
$tests['telnet://rainmaker.wunderground.com:23']=\r\n\r\nx\r\n;
$tests['towel.blinkenlights.nl:666']='';
$tests['telnet://towel.blinkenlights.nl:666']='';
$tests['whois.iana.org:43']=com\r\n;
$tests['telnet://whois.iana.org:43']=com\r\n;
foreach ($tests as $server = $query) {
$result=curl_telnet($query,$server)?'good':'fail';
echo $server=$result\n;
}
?
This results as following:
rainmaker.wunderground.com:23=good
telnet://rainmaker.wunderground.com:23=fail
towel.blinkenlights.nl:666=good
telnet://towel.blinkenlights.nl:666=good
whois.iana.org:43=good
telnet://whois.iana.org:43=fail
The obvious issue is that when you're not using the telnet:// protocol the
HTTP request is always sent. However, in some cases, when a query is sent,
using telnet:// will fail.
Is this a bug or is anyone else able to get telnet with curl to work as
expected?
Thanks.
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, 25 Oct 2010 00:26:23 -0700
Tommy Pham tommy...@gmail.com wrote:
-Original Message-
From: Rico Secada [mailto:coolz...@it.dk]
Sent: Sunday, October 24, 2010 9:06 PM
To: php-general@lists.php.net
Subject: [PHP] Best practice for if (!$stmt-execute())
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid
check and
at
the same time return some kind of valuable db error to the user and
end
the
script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
Rico,
Shouldn't you consider this as what happens, while in production,
should the script fails?, whether its DB related or not. In that
case, how would you want to handle the error? Do you, or the system
admin, want to be notified one way or another of the failure? Do
want to implement a backup in case that failure happens as an
'automatic recovery' mechanism? As a system/network admin, I go by 3
guidelines:
1) Prevent failure as much as I can (either system hardware, software
applications, hacks/exploits/vulnerabilities, etc.).
2) In the event that 1 fails, what's the recovery process? How fast
can I recover from it?
3) If 2 fails, then there's something wrong with the whole process,
which I need to expand my knowledge skillset.
In my past experiences, I haven't yet got to stage 2 because there
precautions you can take to detect when a failure is about to happen
so that stage 2 will never happens. What you need to consider is how
important is this? Is it mission critical?
Regards,
Tommy
Thank you for some very important thoughts! Creating an extended error
handling function seems appropriate.
Regards,
Rico
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, Oct 25, 2010 at 06:06:24AM +0200, Rico Secada wrote:
Hi.
I have been doing like this:
if (!$stmt-execute()) {
return false;
} else {
... some code
return true;
OR
return $foo; // Some int, string, whatever.
}
I am thinking about changing the return false with a:
if (!$stmt-execute()) {
die(DB_ERROR);
This way making sure that every single db execute gets a valid check
and at the same time return some kind of valuable db error to the user
and end the script.
How do you deal with db execution checks?
Thanks in advance!
Best regards.
Rico.
First, there are only a few ways a *true* error can occur with my
database. 1) Bad syntax from the programmer (me). 2) Bad input from the
user (which should never happen). 3) A catastrophic failure on the
database back end.
In all three cases, there is no recovery unless the programmer (me) digs
into the problem. Therefore, I have an error routine used for
everything, which dies and sends the programmer an email with a trace in
the case of a catastrophic error, like the above. And I have a database
wrapper class which checks for errors like this and fires the error
handler if the error is this bad. That means the script will abort and
the programmer will get an email.
Bear in mind, an error is *never* that a query returned no data or
data the user might consider bad.
Paul
--
Paul M. Foster
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Mon, 25 Oct 2010 22:56:37 -0400 Paul M Foster pa...@quillandmouse.com wrote: Bear in mind, an error is *never* that a query returned no data or data the user might consider bad. This is an important point. When is an error an actual error? When is it something that *needs* to be logged and mailed? Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Best practice for if (!$stmt-execute())
On Tue, Oct 26, 2010 at 06:27:33AM +0200, Rico Secada wrote: On Mon, 25 Oct 2010 22:56:37 -0400 Paul M Foster pa...@quillandmouse.com wrote: Bear in mind, an error is *never* that a query returned no data or data the user might consider bad. This is an important point. When is an error an actual error? When is it something that *needs* to be logged and mailed? When it's a programmer/DBA error and cannot be recovered from. For example, the statement: SELECT * WHERE custno = 'BOBSMITH'; contains a syntax error (no table reference). That should generate a fatal error, because no such statement should ever be fired at the DBMS. The programmer should ensure his statements don't contain errors like that. And if they do, there's no way to fix it from a user's perspective. There are any of a number of other PHP errors which will generate error level messages which should lead to fatal errors. The code should now allow such errors. And no user input should create such errors. The programmer has to filter the user's input so that whatever he enters, it doesn't cause PHP or the DBMS to error out that way. These are just definitions of fatal errors from my perspective. Opinions may vary. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
