Re: [PHP-DB] String Parsing/Escaping
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?
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!
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!
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
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