Ok, so getting the content type’s comments into a block is pretty easy once you know how.

This method will require you to use PHP code from within the block you will create to show the comments. So the first thing is to make sure that this is possible by going to site building and then modules and turning on the PHP Filter under the category of Core Optional (if it is not already on that is).

NOTE: Check at admin/settings/filters to be sure that only trusted roles can use the PHP filter, otherwise your web site could be vulnerable to attack. By default, only the administrator can use this filter.

Create a new block and select a region for it. Put the following code on the body textarea:

Do not forget to select the PHP filter from the list of the input filters. After entering the rest of the settings for your block click save.

Now your new block should be ready to assign to whatever region you want. If the page you load has comments related to it. They should now appear via the block.

The arg() funtion may seem a bit cryptic if you’re new to Drupal. Here is a quick explanation from George Notaras in his post: Drupal Tip: List a node’s taxonomy terms inside a Block which I found helpful in compiling this information.

“Now to some technical details about arg(0) and arg(1), which probably seem a bit cryptic to a user that is not experienced with Drupal (like me). Assume we have the following URL to a node: www.example.org/node/23, which means that the path to the page is /node/23. Well, arg(0) is the node part and arg(1) is the second part; 23 that is. Read about the arg() function.”

I hope this was helpful.

What Happens With SQL Injection

By passing an unexpected string of code into a user input, such a form, an attacker send damaging code that causes an otherwise good query to go haywire. For example:

unprotected query is vulnerable

The above snippet of code works as long as users put in the expected information. An attacker, will instead, make clever use of a few extra characters. You likely know by now that SQL requires a semi-colon at the end of each query. PHP automatically adds it in if you omit it. Because of this, the attacker, by closing the string and using the closing parenthesis to finish the query followed by a semi colon, can add an additional query to drop the table.

This is what we in the world of secure web development refer to as a ‘bad thing’!
Scary isn’t it? Attackers have used this method to not only drop tables and destroy records, but also to retrieve highly sensitive information.

How to Protect Against SQL Injection

OK, after that scary bit of information, you’ll be glad to know that protecting yourself is really not all that hard. The hard part is always remembering when and where to do it.

Protecting against SQL Injection is a simple matter of calling a PHP function that renders data safe ( or cleansed ) for use in a query. There are a few methods for cleansing user input in PHP depending on the PHP extension you are using. We will be discussing the mysql extension.The name of the function is:
mysql_real_escape_string(). Notice in this snippet how it is used:

How to protect again SQL Injection

See how easy it is?  Just take the user input (in this case a post ) and pass it through the mysql_real_escape_string() function, (as shown on line 7 ). Then use the “cleansed” variable in the query ( as shown on line 9 ).

It is so easy to protect against this, yet it is often overlooked or forgotten. SO remember to use mysql_real_escape_string() to cleanse your input to help guard against SQL Injection.

There is more to learn and be discussed so feel free to stop back or drop me any suggestions or tips to share.

So, what should be done once you launch your new web site? Well, as proud as you may be of your new creative geniuses, a wise web developer has the humility to recognize that bugs are still likely to surface from time to time. While you do not want any attackers to see error reporting, the information is still valuable to you for squishing bugs. You can (and should) write your error reporting to a file. Actually, PHP does this by default. If you are on a shared server, though, you likely will not have access to this file. You will need to write these errors to your own file.

Don’t Worry, Witting Errors to a File Is Easy
All you need to do is make a few adjustments in you php.ini file. Here are a few php.ini directives that are relevant:

•    display_errors This directive controls whether PHP errors should be sent to the screen. For the production environment this should be turned off.
•    error_reporting This directive controls which errors that should be reported. You should set this to E_ALL and you should fix all issues that appear by doing this.
•    log_errors This directive controls whether errors should be logged to a file. I would recommend that you always turn this on.
•    error_log This is the path of the file errors should be written to. This is only applies if log_errors is turned on obviously.

Your directory structure effects how error_log is set, since it involves creating a path to the error log.

The important thing to remember is that you want to be cautious about what information your error reporting is throwing out to the client. Whenever, possible keep it private. While it should be safely tucked away, it does provide valuable information to you as a web developer. So, keep it handy.

There are many other things to consider in safely setting up a PHP environment with security in mind. We will discuss these in future posts.