Re: [PHP-DB] String Parsing/Escaping

2005-01-09 Thread Jochem Maas
hi Alexander,
interesting question regarding 'safety' v. readability v. speed - I'm 
sure you'll get different views depending on who you ask.

Here is my take:
Alexander Mueller wrote:
Hi,
below are three versions of an SQL call along with escaping the passed 
value.

  $value=mysql_escape_string($_POST['value']);
  mysql_query('SELECT * FROM table WHERE field='.$value.'');
  + Fastest Code
  - Con: Bad Readability, Value needs to be escaped separately
I rate speed as the least important issue - you can alway use a faster 
machine, get some more RAM etc if you really need a quick speed fix.

making the code faster is the last exercise I do in any given project, 
and I almost always choose readability/'safety' over speed


  $value=mysql_escape_string($_POST['value']);
  mysql_query(sprintf('SELECT * FROM table WHERE field=%s', $value));
  + Good Readability
  - Value needs to be escaped separately

This is a compromise - can't imagine why anyone would choose this one.
It's not my choice, I'll just skip to number 3 :-)
sql_sprintf() is a custom version of sprintf() which automatically 
escapes all passed parameters.

  mysql_query(sql_sprintf('SELECT * FROM table WHERE field=%s', 
$_POST['value']));

  + Good Readability, Value does not need to be escaped separately
  - Slowest Code
YEAH!
indeed its the slowest. but its so much more readable and you know its 
alot more maintainable (you don't have to change the escaping, 
sprintf'ing strategy in 100 places.).
Its safer too because there is no chance of forgetting to escape the sql 
args.
I think the speed difference can be measured in milliseconds - are you 
really worried about that? if your app is that heavy that you are trying 
to shave off milliseconds to make it usuable then there are possibly 
bigger problems.
Imagine you have a highly dynamic page that does 50 queries (using the 
3rd technique you proposed), I would guesstimate that refactoring the 
code to do 2-3 less queries per request would get just as much speed 
increase (if not more) than by refactoring the code to use the 1st 
technique on all 50 queries (granted you could refactor both but heh 
there are other things to do than code PHP 24/7 ;-)

in order of importance to me (I often have to maintain/update my code):
1. security
2. readability/maintainability
3. speed/performance
basically the more abstract your code is, the slower it will be - 
because you are asking it to do more for you. to me the extra 
milliseconds wait on a request are worth it, anything to avoid 
debug/maintainance hell!

And if speed really is a big issue - you may need to look into writing 
part of you application logic as a PHP extension (i.e. in C which is way 
faster anyway you cut it.)


...
Thanks,
Alexander
PS: All this code is considered to run under magic_quotes_gpc OFF.
as it should be ;-)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[PHP-DB] Fatal error: Cannot use string offset as an array?

2005-01-09 Thread mdpeters
Fatal error: Cannot use string offset as an array in 

I have a site PHP 5 project that for the most part, works great. I have two 
search links that are broken. They complain about the same error, just another 
line number. I'm not very good with PHP. I am almost certain that this is a 
typo on my part, and I have a good idea what to look for however, I am 
interested in Hiring some PHP guru to examine the code and cut right to the 
repair.

Anyone out there interested?

Best regards,

Michael D. Peters
Director of Security Services
CISSP
Lazarus Alliance Inc.
M: 502-767-3448
O: 502-231-8017 x8
H: 502-231-6923
F: 502-231-5347

[EMAIL PROTECTED]
www.lazarusalliance.com


[PHP-DB] MySQL ENCRYPT help!

2005-01-09 Thread Kevin the Linux User
To the PHP Database Mailing-List:

I joined the mailing list for this one question I just can't figure 
out. I used the phpMyAdmin to create table. I placed one row in this table, I 
used the ENCRYPT function. How do I De-Crypt the data I just encrypted to use 
in my PHP code. I encrypted it, for security.

If it's not a bother, can you also give a sniplet of example code, on 
just the part of de-crypting it, I know everything about connecting, and 
displaying, it's just the de-crypting I am having trouble with.

-- 
Thanks,
Kevin the Linux User
Linux! Working together, we build it BETTER!
-- Quote from book, The Joy of Linux/2001

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DB] MySQL ENCRYPT help!

2005-01-09 Thread Jochem Maas
Kevin the Linux User wrote:
To the PHP Database Mailing-List:
	I joined the mailing list for this one question I just can't figure out. 
nice, we help you and then you bugger off? - community spirit are go!
I used the phpMyAdmin to create table. I placed one row in this table, I used 
the ENCRYPT function. How do I De-Crypt the data I just encrypted to use in my 
PHP code. I encrypted it, for security.
If it's not a bother, can you also give a sniplet of example code, on 
just the part of de-crypting it, I know everything about connecting, and 
displaying, it's just the de-crypting I am having trouble with.
the mysql manual states:
ENCRYPT() ignores all but the first eight characters of str, at least 
on some systems. 

this is probably not what you want, besides which AFAICS its one way 
encryption.

---
as you don't state what it is your trying to achieve (e.g. storing a 
passwd - in which there is NO reason to want to decrypt it - instead you 
should test a user given value against the DB by encrypting the user 
value), you also don't state what version of MySQL your using therefore 
its impossible to determine which encryption functions you have at your 
disposal in MySQL.

here is a couple of pairs of enc/dec funcs that might help:
AES_ENCRYPT(str,key_str)
AES_DECRYPT(crypt_str,key_str)
DECODE(crypt_str,pass_str)
ENCODE(str,pass_str)
try reading this page:
http://dev.mysql.com/doc/mysql/en/Encryption_functions.html
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DB] String Parsing/Escaping

2005-01-09 Thread Alexander Mueller
Jochem Maas wrote:
hi Alexander,
interesting question regarding 'safety' v. readability v. speed - I'm 
sure you'll get different views depending on who you ask.

Here is my take:
Thank you Jochem! :)
I rate speed as the least important issue - you can alway use a faster 
machine, get some more RAM etc if you really need a quick speed fix.

making the code faster is the last exercise I do in any given project, 
and I almost always choose readability/'safety' over speed
I know what you mean and also agree generally, however I am nevertheless 
usually trying to have the code as optimised as possible. If I just knew 
better Assembler I would probably code all my webstuff in .asm files ;D. 
Seriously, I prefer to have code as compact, small, efficient and 
optimised as possible  a personal thing I guess.

This is a compromise - can't imagine why anyone would choose this one.
Well, perhaps because it is a compromise ;). Its readability is much
better than with string concatenation however its performance drop is
still not that bad because its a native function.
YEAH!
indeed its the slowest. but its so much more readable and you know its 
alot more maintainable (you don't have to change the escaping, 
sprintf'ing strategy in 100 places.).
Its safer too because there is no chance of forgetting to escape the sql 
args.
That were also exactly my reasons why I fancied it.
Imagine you have a highly dynamic page that does 50 queries (using the 
3rd technique you proposed), I would guesstimate that refactoring the 
code to do 2-3 less queries per request would get just as much speed 
increase (if not more) than by refactoring the code to use the 1st 
technique on all 50 queries
Thats probably correct.
(granted you could refactor both but heh 
there are other things to do than code PHP 24/7 ;-)
I know, I know  ;)
And if speed really is a big issue - you may need to look into writing 
part of you application logic as a PHP extension (i.e. in C which is way 
faster anyway you cut it.)
Well, my worries now dont go that far :)
Again, thanks very much for sharing your thoughts with me.
Alexander
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php