New Topic/Question
Reply
Problem #1: Error Reporting
Oftentimes I'll be typing along, writing new or modifying some existing code and when I go to test it, BAM, unexpected something in the syntax. Generally this is a missing bracket or parentheses, usually because I had a complex IF statement or added a conditional to section off some code. Of course there are other times that (when using PHP) those end of line semi-colons are missed.
PHP syntax errors are there for a reason, which is why I always say to have PHP (at the ini or .htaccess level) set so that errors are always displayed and error reporting is set to E_ALL or even better E_STRICT. Because otherwise, you'll have no idea what you missed or forgot in terms of syntax.
Having the error reporting turned on should also help you develop better coding practices as well as show you what you could be doing better. (I.e. what PHP complains about but lets you do anyway.)
Additional reading:
http://php.net/manua....display-errors
http://php.net/manua...r-reporting.php
http://php.net/manua...rfunc.constants
Problem #2: SQL Injection
When writing code for oneself, one tends to not care or think there be a need for error reporting. For me, I sit on the fence for this, however WHENEVER I write code for someone else I always try to include some sort of reporting functionality.
Basically, errors should always be raised when data is not what you expect and should always be fatal if you can't continue with what you have. For instance, when you're trying to get the a user's ID number from the cookie to save something to a database, but are only getting "HAHA I HAXED YOU!!!", you should raise some error. Typically I would do something like "Wrong user ID specified." and continue on as if the user was a guest.
I generally raise fatal errors when I'm attempting to send or receive data from a remote source (like a database). Usually when writing a SQL statement, I'll check or otherwise sterilize each piece of data going in so the *SQL won't raise any of it's own errors. However since I can't plan for all situations, it's still good to check the problems. Problems ran into could be anything from people requesting data that's been deleted or even non-existent! Like if I put a topic ID in a URL for Dream.in.Code! Normally I'd never come across a situation where the ID is so high that it hasn't been created yet. However someone who is malicious may try to gain info on the database or even inject his own SQL.
Additional reading:
http://en.wikipedia....i/SQL_injection
SQL Injection: What It Is and How to Prevent It
Problem #3: Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean given
You are assuming that your query was successful and going on to try to process the value returned from mysql_query(). If a query was unsuccessful, then mysql_query returns FALSE, rather than the resource the mysql_fetch_array() function expects.
You can NEVER assume a database query is successful! Use code like this instead:
$sql = "SELECT * from users WHERE username='$username'";
$result = mysql_query($sql) or die("Query $sql failed: " . mysql_error());
This will provide the SQL query sent to the SQL server, in order to debug the failing query. Note that the use of die() here should be replaced in a production environment with proper error handling, including an error logging mechanism to prevent revealing your DB schema.
MultiQuote
| 