I've been a Zend Studio IDE user for about 5 years now. I've always loved the IDE since it was so well tuned for PHP projects. Last year I made the blind leap of faith into using Zend Studio 6.0 and was extremely disappointed in what it provided to the developer. The release had so many bugs and never really stood up well against their previous 5.x release...
When 6.0 was released with all the bugs and issues it contained, I went out of my way to write a 3 page bug list for the team. Why? Because I love Zend and their IDE. It is what makes my life as a developer much easier. I was hoping that pointing out the "features" of 6.0 that was causing so much pain for me to even consider using their product would be enough to send them a message: Change it, or lose yet another developer.
Today I installed Zend Studio 7.0.2 Professional, totally expecting to see these issues resolved. While the IDE shows a drastic change in speed, the same errors and exceptions remain, thus making working in Zend Studio a much more complicated headache than it ever should be.
Granted I would never be able to create the things Zend has for an IDE, however this is not even the case this time. Zend has decided (as of their 6.0 release) to use the Eclipse engine for their IDE. It was a mistake for their 6.0 version, and it's still a mistake today.
The project management piece of Zend Studio (which is the most used functionality for me) is still broken, and management of files is still a clustered mess.
Sigh. While there are a small amount of issues with the 5.5.1 build (which is what I STILL use today), these are NOTHING compared to working with 7.0.2.
I hate to say it, but Zend Studio has lost another developer to use their IDE. I'm done. Their 5.x release was so GREAT! It made life so nice! But now they have continued to stick with the failed philosophy of using Eclipse as their engine (which is actually a decent enough engine), but they just cannot seem to make it work with Zend Studio.
I cannot recommend this IDE to anyone, and I definitely cannot justify spending the amount of cash they (Zend) are calling me asking me to purchase for 7.0.2. There is just no way.
I'll continue to use 5.5.1. Unfortunately though, I can only see nothing but doom for Zend's IDE user base, which is really too bad...
Thursday, November 12, 2009
Monday, November 9, 2009
Simple Optimizing Tips for PHP - Part I
As we write PHP code (or any language for that matter) we begin to start thinking about optimizing code. But even though our intentions are for "the greater good", we sometimes miss things that should be obvious. This article is one of many to come that hopes to point these things out to you, and in the process train your mind to think of quicker steps you may otherwise haven't really thought about.
Today's article takes a look at:
Loop Arrays
When we use loops, the goal is simple: iterate through an array set, and do something with the results. Most developers understand this quite well but they build the basic looping structure without considering how poor methods of iteration will affect their code's performance.
Example:
For some, the problem is quite clear. For others, the code above seems quite valid and perfectly fine. However, the above can cause serious latency in your application(s) if you follow this type of constructing loops enough times.
The issue exists with the loop piece $i < count($rst);
Consider that the query we used returns 2000 records. While the for loop is completely valid, the issue exists in that, for each iteration, you are now counting the number of results ($rst) in each and every iteration!. This means that if we have 2000 records, it's going to get a count of our $rst array 2000 times!
What's worse is that when you issue the count() function on a big array, it must load this array into memory, check it, and then finally clear the tmp data. This in turn puts a small hamper on the server when done once, but when we are doing it 2000 consecutive times just for the sake of iteration, the overhead becomes very evident.
The solution for this is quite simple. You should first just get a count of the number of records, assign it to a value before the loop, and then use this for your iteration. For the PHP engine, is much faster to check a flat numeric value 2000 times rather than issue the count() sequence (explained above) 2000 times.
The Full Solution
Where the above will find some flack from experienced users is the situation where you may really need a count of an array. Such situations include: removing a key from an array, adding a new key to an array, popping values off an array, etc...
For these situations, the solution is not to use a for loop, but rather a foreach loop. Since a foreach loop iterates one array key at a time, we can remove/add array keys without the need to keep a count. Plus, if you really want to keep track of your $i variables count you can just assign $i before foreach loop and increment it within the foreach.
Example:
While the above can be optimized a hundred different ways, the point is that we should be taking into consideration how a script in PHP operates. Instead of just forcing it to carry out redundant operations and continue to put more overhead/waste of processor cycles on our server, why not try to optimize the code and make a cleaner, faster application?
Tune in next week for my next article: Recursive Functions.
Today's article takes a look at:
Loop Arrays
When we use loops, the goal is simple: iterate through an array set, and do something with the results. Most developers understand this quite well but they build the basic looping structure without considering how poor methods of iteration will affect their code's performance.
Example:
$sql = "SELECT * FROM `user`";
$rst = $dbh->fetch_rows($sql);
for($i = 0; $i < count($rst); $i++) {
// do something
}
For some, the problem is quite clear. For others, the code above seems quite valid and perfectly fine. However, the above can cause serious latency in your application(s) if you follow this type of constructing loops enough times.
The issue exists with the loop piece $i < count($rst);
Consider that the query we used returns 2000 records. While the for loop is completely valid, the issue exists in that, for each iteration, you are now counting the number of results ($rst) in each and every iteration!. This means that if we have 2000 records, it's going to get a count of our $rst array 2000 times!What's worse is that when you issue the count() function on a big array, it must load this array into memory, check it, and then finally clear the tmp data. This in turn puts a small hamper on the server when done once, but when we are doing it 2000 consecutive times just for the sake of iteration, the overhead becomes very evident.
The solution for this is quite simple. You should first just get a count of the number of records, assign it to a value before the loop, and then use this for your iteration. For the PHP engine, is much faster to check a flat numeric value 2000 times rather than issue the count() sequence (explained above) 2000 times.
The Full Solution
$sql = "SELECT * from `user`";
$rst = $dbh->fetch_rows($sql);
$total_users = count($rst);
for($i = 0; $i < $total_users; $i++) {
// do something
}
Where the above will find some flack from experienced users is the situation where you may really need a count of an array. Such situations include: removing a key from an array, adding a new key to an array, popping values off an array, etc...
For these situations, the solution is not to use a for loop, but rather a foreach loop. Since a foreach loop iterates one array key at a time, we can remove/add array keys without the need to keep a count. Plus, if you really want to keep track of your $i variables count you can just assign $i before foreach loop and increment it within the foreach.
Example:
$sql = "SELECT * FROM `user`";
$rst = $dbh->fetch_rows($sql);
$i = 0;
foreach($rst as $key => $value) {
echo "|| $key => $value => $i || ";
$i++;
}
While the above can be optimized a hundred different ways, the point is that we should be taking into consideration how a script in PHP operates. Instead of just forcing it to carry out redundant operations and continue to put more overhead/waste of processor cycles on our server, why not try to optimize the code and make a cleaner, faster application?
Tune in next week for my next article: Recursive Functions.
Wednesday, November 4, 2009
PHP Coding Standards
I wrote this a few years ago in order to create a more standard approach to developing PHP code. Enjoy...
PHP Coding Standards
Contents
1 PHP Coding Standards
2 Benefits of Coding Standards
3 Coding Standard Used in this Document
4 Identifier Naming
5 Keep Functions to a Maximum of One Page
6 Whitespace and Indentation
7 Placement of Parenthesis and Curly Braces
8 Line Up Like Values
9 Add a Space between Variable Definitions
10 File Structure and File Naming (More Work Needed in this section)
11 Comments
12 A Full Example
13 Conclusion
14 References
PHP Coding Standards
This document provides a complete coding standard to resolve conflicts that may arise when developers share and/or debug code. It is important for every developer to understand the benefits of such standards, how to use them and how not doing so affects others. Each developer adapts to their own methods and forcing them to change usually results in a negative result.
With that being said, it is encouraged rather than required that you follow this standard. Coding standards do not have to be a difficult thing to conform to. They actually do more good than bad, especially in an environment where such standards do not already exist. This document's intension is to put standards to use and make for a more team-friendly development environment.
Benefits of Coding Standards
Standards benefit both developers and businesses alike. It applies conventions that make it significantly easier for both current and subsequent developers to understand how the application they work on operates. It also helps with how to fix or extend existing code for new needs.
Example:
$a = $b * c;
The above is 100% valid and works, but it's very unclear to its true meaning. What are the variables true representations? How hard is it going to be when we have more variables like $aa, $az, $z, or others that obfuscate this further?
A Standard-Correct Example:
$weekly_pay = $hours_worked * $pay_rate
This describes both the intent and meaning of the variables, the end result and makes it very easy for anyone else to decipher who may stumble upon this line.
Coding standards also are beneficial in that when used, they can enable a transparency to the code, eases debugging and can increase code maintainability.
Quote from the Java Standards Webpage:
Coding Standard Used in this Document
The coding standard used in this document is very closely tied to the C++ (and C) language called the Kernighan and Ritchie (K&R) standard.
There are other standards (including the ANSI C++ standard, Java standard, Pascal Standard and hundreds others) that developers use, but this standard is much more universal in many ways. The primary way being that it conforms to other adapted models outside of programming (such as the MySQL and SQL database server's standards) and has been widely used for over a decade now.
Identifier Naming
Identifiers are names given to variables, functions, objects, etc.
Given this understanding, you should follow these rules when defining an Identifier:
1) Do not use a leading underscore. They are usually reserved for compiler or internal variables of a language and can mislead a developer into thinking it's a SYSTEM identifier instead of a custom built one. Example of an incorrect name: $_first_name;
2) Do not use names that are like standard system identifiers as these words are reserved words for a reason, and doing so will make the application more difficult to understand. Example of an incorrect name: $for;
3) Give descriptive meaning to identifier names. Example of a bad name: $fn Example of a good name: $first_name. However, make sure to keep in mind not to get too descriptive since this will result in a lot of typing for the rest. Try to keep it short, but to the point. This rule can also be relaxed a little more for instances where short variable names such as $i are used in for loops.
4) Give descriptive meaning for functions that contain a mix of verbs and nouns separated by underscores.
Bad Example:
function first_name() {
Good Example:
function get_first_name() {
Once again, this is considered the K&R standard. The other method is the ANSI C++ Standard, which capitalizes the first letter in each word (getFirstName). However, since we are using the K&R Standard in this document, it is required you follow the K&R naming conventions. Function names can easily be dismissed by a developer who is in the heat of the moment in code. It's very easy to call a function "doit" instead of "get_first_name".
Keep Functions to a Maximum of One Page
This is not an absolute rule as much as it is a helpful practice. Functions that exceed 1 page are by default a little harder to decipher both during creation as well as debugging. Scrolling up and down a page can cause confusion as to what function you are in, where the braces line up, and also how something in the beginning of the function worked. This becomes more evident when opening a file in a console editor like VI or EMACs.
Plus, if you find yourself writing more than a page for a function, it may be a very good indication that you might need to break the function down to 2 or more separate functions, that the function could instead be used as a recursive function, or simply that the method you are choosing is not the quickest route.
This does not mean that you should obfuscate your code in order to meet this requirement. If the function absolutely must extend a page (and usually this is the case when formatting arrays correctly) then go ahead and do it. Just keep it in your head that if you can put a piece of code in its own separate function to be used later, do it.
Whitespace and Indentation
Most modern editors today allow you to define how many spaces a tab can be. They also offer the ability to decide if you would rather use the tab (\t) character when the TAB key is pressed, or if the TAB should be interpreted as X number of spaces.
The preferred method is that all TABS be handled as spaces with 2 spaces as the default (4 is usually the system default). If you are used to the standard Window's tab of 4 spaces, this may seem a little awkward at first. Rest assured, it will reduce the number of column space your code is taking up, but also give it a more structured and easier flow.
Finally, it should also be common practice to change how new lines are handled with your IDE. The default should be set to treat new lines as the Unix \n (new line) instead of the Microsoft default \r (Return). The reason is that \n is a universal default supported in all Operating Systems, so no matter what OS your code is opened up in, the new lines will be nicely available on each new line instead of one concurrent line.
Placement of Parenthesis and Curly Braces
This is perhaps one of the most difficult subjects, not because of its complexity, but more of an infringement of a developer's habit. The ANSI C++ standard has us put curly braces on their own separate lines after ifs, loops, function declarations, etc. The K&R standard, however, has us put curly braces on the same line.
Example ANSI C++ Standard
K&R 1TBS Standard Example
This document requires you to use the K&R Standard as was first defined in the beginning of this text. It is very important that this method be used in order to reduce the need of other developers to reformat your code in order to bring it up to scope with this standard.
Line Up Like Values
When you have a list of variable declarations, or a large array definition, it's a good idea to line these values up. It helps with readability and is key to making your code clean for other developers.
Bad Example
$first_name = 'John';
$last_name = 'Doe';
$city = 'Cincinnati';
Good Example
As you can see, the second example makes it much more legible. One more exaple would be for an array;
Bad Example:
Array('first_name' => 'John', 'last_name' => 'Doe', 'city' => 'Cincinnati', 'address' => array('street' => 'PO Box 20', 'zip' => '45241'));
Good Example:
Add a Space between Variable Definitions
When defining a variable to be equal to a value, always make sure to put a space between the variable and the equal sign, and also a space between the equal sign and the value.
Bad Example:
$i=0;
function foo($bar=1){
}
Good Example:
$i = 0;
function foo($bar = 1) {
}
Filesystem Naming Conventions (Files/Directories)
Both files and directories should be named by default by all lower-case. They should be descriptive in their meaning, but also limited in length. This is not only because both Linux and Unix servers are case-sensitive file systems, but also because even web addresses typed in capitalized lettering will, by default, be translated as lower-case values (IE: WWW.GOOGLE.COM will be switched to www.google.com on Enter).
A typical file structure should have the following structure:
The admin directory is where backend application files that would require a login and admins a page should go. The apps directory has 2 sub directories: includes and classes. Includes are files that are included simply to reduce repetition (such as header or footer files), whereas classes is where files containing class definitions are stored. The css directory, as the name implies, is where style sheet (css) files will go. The js directory is where JavaScript files would go. The utils directory is where either 3rd party applications or reusable applications (such as thumbnail generators) would go. The xml directory is where xml files will go.
Example of a bad filename
1.php
Example of a GOOD filename
list_users.php
Comments
Comments play a major role in any development environment. It not only helps out an individual better debug their own code, but it is basically a manual to how your code works. Commenting should follow the DOC standard for commenting.
The following is an example of this:
Commenting is vital with any team. Over commenting can cause your code to be very confusing, under commenting could leave many questions regarding what your code actually does.
You should always comment in these circumstances:
The PHPdoc comment is very intuitive and supported by most popular IDE's.
Some of the most popular keys used with this commenting style are:
A Full Example
Conclusion
This is the end of the current Coding Standards document. There are a few other concepts such as private/public variables, unit naming, and other high-end programming techniques that can be applied, but are not due to this not being about "how to program", but instead is about coding standards.
References
http://en.wikipedia.org/wiki/Coding_standard - Wikipedia Definition of a Coding Standard
http://en.wikibooks.org/wiki/C%2B%2B_Programming/Code_Style - Code Standards
http://en.wikipedia.org/wiki/Indent_style - K&R Coding Style Definition
http://dn.codegear.com/article/10280/Code - Great Article relating to the K&R Coding Style
/**
* @author Jonathon Hibbard
*/
PHP Coding Standards
Contents
1 PHP Coding Standards
2 Benefits of Coding Standards
3 Coding Standard Used in this Document
4 Identifier Naming
5 Keep Functions to a Maximum of One Page
6 Whitespace and Indentation
7 Placement of Parenthesis and Curly Braces
8 Line Up Like Values
9 Add a Space between Variable Definitions
10 File Structure and File Naming (More Work Needed in this section)
11 Comments
12 A Full Example
13 Conclusion
14 References
PHP Coding Standards
This document provides a complete coding standard to resolve conflicts that may arise when developers share and/or debug code. It is important for every developer to understand the benefits of such standards, how to use them and how not doing so affects others. Each developer adapts to their own methods and forcing them to change usually results in a negative result.
With that being said, it is encouraged rather than required that you follow this standard. Coding standards do not have to be a difficult thing to conform to. They actually do more good than bad, especially in an environment where such standards do not already exist. This document's intension is to put standards to use and make for a more team-friendly development environment.
Benefits of Coding Standards
Standards benefit both developers and businesses alike. It applies conventions that make it significantly easier for both current and subsequent developers to understand how the application they work on operates. It also helps with how to fix or extend existing code for new needs.
Example:
$a = $b * c;
The above is 100% valid and works, but it's very unclear to its true meaning. What are the variables true representations? How hard is it going to be when we have more variables like $aa, $az, $z, or others that obfuscate this further?
A Standard-Correct Example:
$weekly_pay = $hours_worked * $pay_rate
This describes both the intent and meaning of the variables, the end result and makes it very easy for anyone else to decipher who may stumble upon this line.
Coding standards also are beneficial in that when used, they can enable a transparency to the code, eases debugging and can increase code maintainability.
Quote from the Java Standards Webpage:
"Why have code conventions?
Code conventions are important to programmers for a number of reasons:
* 80% of the lifetime cost of a piece of software goes to maintenance.
* Hardly any software is maintained for its whole life by the original author
* Code conventions improve the readability of the software,
allowing engineers to understand new code more quickly and thoroughly."
Coding Standard Used in this Document
The coding standard used in this document is very closely tied to the C++ (and C) language called the Kernighan and Ritchie (K&R) standard.
There are other standards (including the ANSI C++ standard, Java standard, Pascal Standard and hundreds others) that developers use, but this standard is much more universal in many ways. The primary way being that it conforms to other adapted models outside of programming (such as the MySQL and SQL database server's standards) and has been widely used for over a decade now.
Identifier Naming
Identifiers are names given to variables, functions, objects, etc.
Given this understanding, you should follow these rules when defining an Identifier:
1) Do not use a leading underscore. They are usually reserved for compiler or internal variables of a language and can mislead a developer into thinking it's a SYSTEM identifier instead of a custom built one. Example of an incorrect name: $_first_name;
2) Do not use names that are like standard system identifiers as these words are reserved words for a reason, and doing so will make the application more difficult to understand. Example of an incorrect name: $for;
3) Give descriptive meaning to identifier names. Example of a bad name: $fn Example of a good name: $first_name. However, make sure to keep in mind not to get too descriptive since this will result in a lot of typing for the rest. Try to keep it short, but to the point. This rule can also be relaxed a little more for instances where short variable names such as $i are used in for loops.
4) Give descriptive meaning for functions that contain a mix of verbs and nouns separated by underscores.
Bad Example:
function first_name() {
Good Example:
function get_first_name() {
Once again, this is considered the K&R standard. The other method is the ANSI C++ Standard, which capitalizes the first letter in each word (getFirstName). However, since we are using the K&R Standard in this document, it is required you follow the K&R naming conventions. Function names can easily be dismissed by a developer who is in the heat of the moment in code. It's very easy to call a function "doit" instead of "get_first_name".
Keep Functions to a Maximum of One Page
This is not an absolute rule as much as it is a helpful practice. Functions that exceed 1 page are by default a little harder to decipher both during creation as well as debugging. Scrolling up and down a page can cause confusion as to what function you are in, where the braces line up, and also how something in the beginning of the function worked. This becomes more evident when opening a file in a console editor like VI or EMACs.
Plus, if you find yourself writing more than a page for a function, it may be a very good indication that you might need to break the function down to 2 or more separate functions, that the function could instead be used as a recursive function, or simply that the method you are choosing is not the quickest route.
This does not mean that you should obfuscate your code in order to meet this requirement. If the function absolutely must extend a page (and usually this is the case when formatting arrays correctly) then go ahead and do it. Just keep it in your head that if you can put a piece of code in its own separate function to be used later, do it.
Whitespace and Indentation
Most modern editors today allow you to define how many spaces a tab can be. They also offer the ability to decide if you would rather use the tab (\t) character when the TAB key is pressed, or if the TAB should be interpreted as X number of spaces.
The preferred method is that all TABS be handled as spaces with 2 spaces as the default (4 is usually the system default). If you are used to the standard Window's tab of 4 spaces, this may seem a little awkward at first. Rest assured, it will reduce the number of column space your code is taking up, but also give it a more structured and easier flow.
Finally, it should also be common practice to change how new lines are handled with your IDE. The default should be set to treat new lines as the Unix \n (new line) instead of the Microsoft default \r (Return). The reason is that \n is a universal default supported in all Operating Systems, so no matter what OS your code is opened up in, the new lines will be nicely available on each new line instead of one concurrent line.
Placement of Parenthesis and Curly Braces
This is perhaps one of the most difficult subjects, not because of its complexity, but more of an infringement of a developer's habit. The ANSI C++ standard has us put curly braces on their own separate lines after ifs, loops, function declarations, etc. The K&R standard, however, has us put curly braces on the same line.
Example ANSI C++ Standard
if (this_condition == true)
{
//do something
}
else {
//do something else
}
K&R 1TBS Standard Example
if(this_condition == true) {
//do something
} else {
//do something else
}
This document requires you to use the K&R Standard as was first defined in the beginning of this text. It is very important that this method be used in order to reduce the need of other developers to reformat your code in order to bring it up to scope with this standard.
Line Up Like Values
When you have a list of variable declarations, or a large array definition, it's a good idea to line these values up. It helps with readability and is key to making your code clean for other developers.
Bad Example
$first_name = 'John';
$last_name = 'Doe';
$city = 'Cincinnati';
Good Example
$first_name = 'John';
$last_name = 'Doe';
$city = 'Cincinnati';
As you can see, the second example makes it much more legible. One more exaple would be for an array;
Bad Example:
Array('first_name' => 'John', 'last_name' => 'Doe', 'city' => 'Cincinnati', 'address' => array('street' => 'PO Box 20', 'zip' => '45241'));
Good Example:
Array('first_name' => 'John',
'last_name' => 'Doe',
'city' => 'Cincinnati',
'address' => array('street' => 'PO Box 20',
'zip' => '45241',
),
);
Add a Space between Variable Definitions
When defining a variable to be equal to a value, always make sure to put a space between the variable and the equal sign, and also a space between the equal sign and the value.
Bad Example:
$i=0;
function foo($bar=1){
}
Good Example:
$i = 0;
function foo($bar = 1) {
}
Filesystem Naming Conventions (Files/Directories)
Both files and directories should be named by default by all lower-case. They should be descriptive in their meaning, but also limited in length. This is not only because both Linux and Unix servers are case-sensitive file systems, but also because even web addresses typed in capitalized lettering will, by default, be translated as lower-case values (IE: WWW.GOOGLE.COM will be switched to www.google.com on Enter).
A typical file structure should have the following structure:
/admin/
/apps/
|- classes
|- includes
/css/
/js/
/utils/
/xml/
The admin directory is where backend application files that would require a login and admins a page should go. The apps directory has 2 sub directories: includes and classes. Includes are files that are included simply to reduce repetition (such as header or footer files), whereas classes is where files containing class definitions are stored. The css directory, as the name implies, is where style sheet (css) files will go. The js directory is where JavaScript files would go. The utils directory is where either 3rd party applications or reusable applications (such as thumbnail generators) would go. The xml directory is where xml files will go.
Example of a bad filename
1.php
Example of a GOOD filename
list_users.php
Comments
Comments play a major role in any development environment. It not only helps out an individual better debug their own code, but it is basically a manual to how your code works. Commenting should follow the DOC standard for commenting.
The following is an example of this:
/**
* A brief description of what you are commenting goes here.
*/
Commenting is vital with any team. Over commenting can cause your code to be very confusing, under commenting could leave many questions regarding what your code actually does.
You should always comment in these circumstances:
* Whenever you define a function or class
* Whenever you define a variable that does not describe itself properly.
* Whenever you write a "hack".
* Whenever a block of code is foreign to you.
* Every new page you create should have a description at the top indicating its purpose.
* If something you do is not 100% and needs to be rewritten in the future.
* If something you do is not 100% obvious.
The PHPdoc comment is very intuitive and supported by most popular IDE's.
Some of the most popular keys used with this commenting style are:
@author // Indicates the author's name
@param // Describes a parameter for a function
@copyright // The copyright information (if applicable).
@return // The return value of a function
@todo // Gives you the ability to write-up a "todo" list.
A Full Example
/**
* @author John Doe
* This class' purpose is to provide a control area for handling database connections,
* errors and results.
*
* @copyright ACME
* @todo This class requires a new method of error control.
*/
class db_handle {
/**
* This is the database handler variable.
*/
public $dbh;
/**
* This is the constructor of the class.
* @param string $strDSN // String containg connection information
* @return object // Returns the db_handle object.
*/
public function __construct($strDSN) {
// Do Something.
}
}
Conclusion
This is the end of the current Coding Standards document. There are a few other concepts such as private/public variables, unit naming, and other high-end programming techniques that can be applied, but are not due to this not being about "how to program", but instead is about coding standards.
References
http://en.wikipedia.org/wiki/Coding_standard - Wikipedia Definition of a Coding Standard
http://en.wikibooks.org/wiki/C%2B%2B_Programming/Code_Style - Code Standards
http://en.wikipedia.org/wiki/Indent_style - K&R Coding Style Definition
http://dn.codegear.com/article/10280/Code - Great Article relating to the K&R Coding Style
Friday, January 9, 2009
When and How to Use Cookies
(Disclaimer: The methods described below should be viewed as education purposes only! These methods are not certified by me to stop or prevent attacks to your site. Instead, this blog tries to explain some ideas for properly using cookies. In other words, use these methods at your own risk, but don't come looking to sue me if you or your site are compromised).
Cookies, by some, are one of God's greatest inventions for the Internet. To others, cookies represent all that is bad and evil in the world today.
In reality, they are both.
These little files are only as good or bad as you, the developer, use them. With the growing popularity in XSS Attacks and CSRF Attacks, there is no wonder developers are having trouble relating anything good with using cookies, and also why even more users are refusing to accept them.
In this blog entry, I'll explain to you how to make using cookies on your site safer by explaining the following:
When to use cookies, and when not to use cookies
How to properly validate users with cookies
Alternatives to using client-side cookies
References/Further Reading
When to use cookies
Cookies, by many sites in the past and, unfortunately, the present, are mainly used to identify a user who has access to a website. They are intended to be a beneficial file(s) that grants users a more pleasant experience while they are browsing, shopping, or later return to a site, without the need to retype their credentials. However, the same helpful intentions of cookies such as these are continually being turned into unpleasant security vulnerabilities for users and websites alike.
We first start with when not to use cookies.
Cookies should not be used to store sensitive information. To be more blunt, you shouldn't store unencrypted (or plain-text) values for usernames, credit card information, first/last names, addresses, phone/fax/mobile numbers, passwords, email addresses, websites, social security numbers...you get the drift. Nothing personally related to your user nor anything that will be used to automatically authenticate/login a user should be available in a cookie.
While select few will scream “blasphemy” at such an idea, I assure you it is not I who is blaspheming. It is a common misconception for developers to think cookies are a safe warehouse for information. Such carelessness is leading the current craze of XSS and CSRF attacks among crackers (poorly and misleadingly labeled hackers) to be legit methods to obtain or attack a user/website.
So what should cookies be used for then?
Cookies should be used for simple and harmless storage, and/or by validating that an actual user is submitting a form from within your website (for examples using the form method, please see Preventing CSRF andXSRF Attack link below).
Some Ideas of simple storage:
Keeping track of a shopping cart of an unregistered user (registered users have the luxury of that information being stored in a database).
Remembering which test/quiz/questionnaire/poll a user has already completed.. Of course, I do not mean for use with prize-based poll/questionnaire/etc. These should be limited to registered users and, like before, stored in a database.
Tracking when a user is logged into your site to assist and report “Number of active/Logged In Users” status.
All of these methods are simple, and harmless uses to store cookie data. But like any other data coming from a user to your site, the above must always be validated. You must be as paranoid as possible when dealing with data coming from your client, and validate everything, always. Assuming that no one cares about your website, or that it's unlikely a cracker would ever want to take over your website is exactly why a cracker would choose to take over your site. The majority of crackers do this in order to obtain popularity within their group (or bragging rights if you will), and when one finds out it's possible, the majority of the others will follow in order to gain the same bragging rights. All courtesy of your website's vulnerabilities.
In general remember to just keep it simple, keep it light, and make values you store in a cookie obfuscated as well. If you want to store the ID of an item, name the cookie “session_id_for_user” and the ID the item_id multiplied by some integer and combination of letters/numbers.
Example:
Assume you sale Bourbon, and the George T. Stagg has an item_id of 15. The value you should store in the cookie should be b375gts. In other words, b(for bourbon), 375 (which is 15 x 25), and gts (the initials for George T Stagg).
Don't go using my example though. Be creative! Be obtrusive! The harder it is for a cracker to understand just exactly what your cookie values do, the harder it's going to be for them to realize that it's a worthless cookie to begin with.
How to properly validate users with cookies
One of the most popular things a developer wants to do anymore with cookies is allow for a returning user to have a more pleasant experience on their site by not needing to enter as much data to gain access. But since we've already stated that storing information used to authenticate a user is not only dangerous, but shouldn't be used, how should we go about granting users some sort of relief?
The answer, just like above, is an obfuscated encryption key that is used to lookup a user_id in a database, but requires the user to type in their password. Once the encryption key is used and the correct password entered, the current encrypted key is discarded, and a new one is generated.
While this may sound like it contradicts my statements earlier, it is in fact a legitimate method! How can this be? Well, first of all an encrypted hash generated from a combination of the user's browser agent (ie: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5), a current timestamp (12388445), parts of the person's username and email address (smashed123 becomes maed23 and bob@gmail.com becomes omilom), all encrypted with SHA or MD5 (although there are numerous rumors about MD5 quickly becoming an insecure encryption). Now you have a nice, simple, and (for now) safe encryption. One that, even if decrypted, would be meaningless/useless to the cracker who attempts to hijack it.
And since we are still requiring the user to type in their password to the site in order to accurately authenticate them further, off-site attacks are even more less likely.
Even after all of this, I still do not use cookies for validating a user's login credentials. Unfortunately, I would rather suffer from losing a lazy user to giving an attacker even 1 iota of an advantage, no matter how good the methods appears.
Alternatives to using client-side cookies
There are of course alternatives to using cookies. Since I am more of a PHP fan, I will use PHP's server-side sessions as an example.
PHP stores sessions 3 ways: via cookies on the client site (which, if used, should be used in conjunction with the session.cookie_httponly setting to help reduce XSS vulnerability), on the filesystem of the server (usually located in /tmp with a hash value), or in the server's memory (not covered or recommended).
Since we're only looking at server-side methods, obviously that leaves server-side-based cookies. While this method is much more secure and reliable, it is still strongly recommended to follow the above guidelines when determining what sort of data to store inside of a session-based cookie.
Resources/Further Reading
Preventing CSRF and XSRF Attacks
The Felten and Zeller Paper (PDF)
Cross-site Scripting Prevention/Awareness
In conclusion, I hope this has been helpful in some way to anyone interested in security. While some of the above almost certainly can be improved on (and I truly hope the development community tries to assist in doing just that), I welcome any and all comments.
Cookies, by some, are one of God's greatest inventions for the Internet. To others, cookies represent all that is bad and evil in the world today.In reality, they are both.
These little files are only as good or bad as you, the developer, use them. With the growing popularity in XSS Attacks and CSRF Attacks, there is no wonder developers are having trouble relating anything good with using cookies, and also why even more users are refusing to accept them.
In this blog entry, I'll explain to you how to make using cookies on your site safer by explaining the following:
When to use cookies, and when not to use cookies
How to properly validate users with cookies
Alternatives to using client-side cookies
References/Further Reading
When to use cookies
Cookies, by many sites in the past and, unfortunately, the present, are mainly used to identify a user who has access to a website. They are intended to be a beneficial file(s) that grants users a more pleasant experience while they are browsing, shopping, or later return to a site, without the need to retype their credentials. However, the same helpful intentions of cookies such as these are continually being turned into unpleasant security vulnerabilities for users and websites alike.
We first start with when not to use cookies.
Cookies should not be used to store sensitive information. To be more blunt, you shouldn't store unencrypted (or plain-text) values for usernames, credit card information, first/last names, addresses, phone/fax/mobile numbers, passwords, email addresses, websites, social security numbers...you get the drift. Nothing personally related to your user nor anything that will be used to automatically authenticate/login a user should be available in a cookie.
While select few will scream “blasphemy” at such an idea, I assure you it is not I who is blaspheming. It is a common misconception for developers to think cookies are a safe warehouse for information. Such carelessness is leading the current craze of XSS and CSRF attacks among crackers (poorly and misleadingly labeled hackers) to be legit methods to obtain or attack a user/website.
So what should cookies be used for then?
Cookies should be used for simple and harmless storage, and/or by validating that an actual user is submitting a form from within your website (for examples using the form method, please see Preventing CSRF andXSRF Attack link below).
Some Ideas of simple storage:
Keeping track of a shopping cart of an unregistered user (registered users have the luxury of that information being stored in a database).
Remembering which test/quiz/questionnaire/poll a user has already completed.. Of course, I do not mean for use with prize-based poll/questionnaire/etc. These should be limited to registered users and, like before, stored in a database.
Tracking when a user is logged into your site to assist and report “Number of active/Logged In Users” status.
All of these methods are simple, and harmless uses to store cookie data. But like any other data coming from a user to your site, the above must always be validated. You must be as paranoid as possible when dealing with data coming from your client, and validate everything, always. Assuming that no one cares about your website, or that it's unlikely a cracker would ever want to take over your website is exactly why a cracker would choose to take over your site. The majority of crackers do this in order to obtain popularity within their group (or bragging rights if you will), and when one finds out it's possible, the majority of the others will follow in order to gain the same bragging rights. All courtesy of your website's vulnerabilities.
In general remember to just keep it simple, keep it light, and make values you store in a cookie obfuscated as well. If you want to store the ID of an item, name the cookie “session_id_for_user” and the ID the item_id multiplied by some integer and combination of letters/numbers.
Example:
Assume you sale Bourbon, and the George T. Stagg has an item_id of 15. The value you should store in the cookie should be b375gts. In other words, b(for bourbon), 375 (which is 15 x 25), and gts (the initials for George T Stagg).
Don't go using my example though. Be creative! Be obtrusive! The harder it is for a cracker to understand just exactly what your cookie values do, the harder it's going to be for them to realize that it's a worthless cookie to begin with.
How to properly validate users with cookies
One of the most popular things a developer wants to do anymore with cookies is allow for a returning user to have a more pleasant experience on their site by not needing to enter as much data to gain access. But since we've already stated that storing information used to authenticate a user is not only dangerous, but shouldn't be used, how should we go about granting users some sort of relief?
The answer, just like above, is an obfuscated encryption key that is used to lookup a user_id in a database, but requires the user to type in their password. Once the encryption key is used and the correct password entered, the current encrypted key is discarded, and a new one is generated.
While this may sound like it contradicts my statements earlier, it is in fact a legitimate method! How can this be? Well, first of all an encrypted hash generated from a combination of the user's browser agent (ie: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.04 (hardy) Firefox/3.0.5), a current timestamp (12388445), parts of the person's username and email address (smashed123 becomes maed23 and bob@gmail.com becomes omilom), all encrypted with SHA or MD5 (although there are numerous rumors about MD5 quickly becoming an insecure encryption). Now you have a nice, simple, and (for now) safe encryption. One that, even if decrypted, would be meaningless/useless to the cracker who attempts to hijack it.
And since we are still requiring the user to type in their password to the site in order to accurately authenticate them further, off-site attacks are even more less likely.
Even after all of this, I still do not use cookies for validating a user's login credentials. Unfortunately, I would rather suffer from losing a lazy user to giving an attacker even 1 iota of an advantage, no matter how good the methods appears.
Alternatives to using client-side cookies
There are of course alternatives to using cookies. Since I am more of a PHP fan, I will use PHP's server-side sessions as an example.
PHP stores sessions 3 ways: via cookies on the client site (which, if used, should be used in conjunction with the session.cookie_httponly setting to help reduce XSS vulnerability), on the filesystem of the server (usually located in /tmp with a hash value), or in the server's memory (not covered or recommended).
Since we're only looking at server-side methods, obviously that leaves server-side-based cookies. While this method is much more secure and reliable, it is still strongly recommended to follow the above guidelines when determining what sort of data to store inside of a session-based cookie.
Resources/Further Reading
Preventing CSRF and XSRF Attacks
The Felten and Zeller Paper (PDF)
Cross-site Scripting Prevention/Awareness
In conclusion, I hope this has been helpful in some way to anyone interested in security. While some of the above almost certainly can be improved on (and I truly hope the development community tries to assist in doing just that), I welcome any and all comments.
Wednesday, January 7, 2009
Facebook - You're killing me smalls!
About 4 months ago, I began making my transition from MySpace over to the Facebook realm. Until recently, I had the utmost respect for Facebook, it's interface, how it works, and all that jazz.
As I said, that is until recently.
That is until I started getting all sorts of emails out of the blue. "What the hell??", I asked myself. Was Facebook selling my account information to a 3rd party? Were they spamming me to make an extra buck?
The answer to all of these questions is "No" - at least not on purpose.
For any tech nerd out there who knows anything at all about Cookies, Sessions, and Security from building a website, you know some pretty common rules when it comes to user information.
1) Don't put any sensitive information in the cookie that you yourself wouldn't want the whole ever-loving world to know about.
2) Don't trust that cookie data. It should be there as a means of "Quick Lookup" ONLY!
3) DON'T PUT ANY SENSITIVE INFORMATION IN THE COOKIE!!
Facebook, being the big powerhouse social networking site that they are, should of all people be more than aware of this. They should know that setting a cookie called "login_x" with my username (which is my email address too by the way) in there is a HUGE no-no! Worse yet, it's in plain text to boot!!
Well, maybe I'm over-reacting a little bit. I mean, it is quote/unquote encrypted with url encode!
COME ON GUYS! What the heck gives with this crap?
Given the fact that a LOT more Cookie Sniffing sites are coming out, wouldn't it be pretty obvious that this is yet another great way to have the security on your site compromised, or even worse, a great way for my personal information to get out?! A simple lookup of the email from google, and more than likely you're also going to know that Person's First and Last Name. With that, if the user, say, owns a few domain names? A quick whois on those domains and you now have their address and phone number too! All this information in a matter of seconds if you have written a script to just do the leg work for you, or a couple minutes if you're a teenager with a desire to be a haxx0r.
Now, in case there are any nay sayers out there who think that cookies are part of Satan's toolkit and that only a moron would store them, just hold on a second. Cookies can be good for a number of reasons, like storing a counter, the number of the last post you read, or something else insignificant that would just make your user's experience a tad bit better. Hell, maybe I'll even write a blog on the goods and bads of cookies. Either way, there are ways to use a cookie and there are ways NOT to use a cookie. For a good show in how not to, just use Facebook as an example.
Don't get me wrong, I still love Facebook as an application, and I'll still use it since I've put way too much time into it as it is. However, I for one am going to try and block any and all cookies from this moment on from Facebook.
I mean, MySpace isn't exactly the greatest site on the planet, but hey, at least they aren't storing sensitive information like this in plain text for the world to see...
As I said, that is until recently.
That is until I started getting all sorts of emails out of the blue. "What the hell??", I asked myself. Was Facebook selling my account information to a 3rd party? Were they spamming me to make an extra buck?
The answer to all of these questions is "No" - at least not on purpose.
For any tech nerd out there who knows anything at all about Cookies, Sessions, and Security from building a website, you know some pretty common rules when it comes to user information.
1) Don't put any sensitive information in the cookie that you yourself wouldn't want the whole ever-loving world to know about.
2) Don't trust that cookie data. It should be there as a means of "Quick Lookup" ONLY!
3) DON'T PUT ANY SENSITIVE INFORMATION IN THE COOKIE!!
Facebook, being the big powerhouse social networking site that they are, should of all people be more than aware of this. They should know that setting a cookie called "login_x" with my username (which is my email address too by the way) in there is a HUGE no-no! Worse yet, it's in plain text to boot!!
Well, maybe I'm over-reacting a little bit. I mean, it is quote/unquote encrypted with url encode!
COME ON GUYS! What the heck gives with this crap?
Given the fact that a LOT more Cookie Sniffing sites are coming out, wouldn't it be pretty obvious that this is yet another great way to have the security on your site compromised, or even worse, a great way for my personal information to get out?! A simple lookup of the email from google, and more than likely you're also going to know that Person's First and Last Name. With that, if the user, say, owns a few domain names? A quick whois on those domains and you now have their address and phone number too! All this information in a matter of seconds if you have written a script to just do the leg work for you, or a couple minutes if you're a teenager with a desire to be a haxx0r.
Now, in case there are any nay sayers out there who think that cookies are part of Satan's toolkit and that only a moron would store them, just hold on a second. Cookies can be good for a number of reasons, like storing a counter, the number of the last post you read, or something else insignificant that would just make your user's experience a tad bit better. Hell, maybe I'll even write a blog on the goods and bads of cookies. Either way, there are ways to use a cookie and there are ways NOT to use a cookie. For a good show in how not to, just use Facebook as an example.
Don't get me wrong, I still love Facebook as an application, and I'll still use it since I've put way too much time into it as it is. However, I for one am going to try and block any and all cookies from this moment on from Facebook.
I mean, MySpace isn't exactly the greatest site on the planet, but hey, at least they aren't storing sensitive information like this in plain text for the world to see...
Thursday, December 18, 2008
Future of the Web
So what's keeping me awake the past few nights is thinking about what is going to come next. The world was taken by storm from the whole "Web 2.0" craze (or Y2k part 2 if you ask me), but what's key here is that there really *is* a next step in technology.
That next step is Mobile...
I've been a mobile advocate since I learned how to send and receive to my Sony Ericson Z500a about 3-4 years ago. Since then, I started following trends with the new Mobile Web Standards that came out in 2005/06. When the world started seeing that it was possible to design sites around phones, the cell companies started to see a drastic increase in sales. The problem though, was phones just didn't have the resolution, the processor power, nor any other great qualities that made home computers the best user experience for surfing the web. This caused many to think it was just another fad and that mobile web would eventually just go away.
But the happy fact is that it didn't go away, and it has actually started growing faster every single quarter. I think I predicted 2 years ago that 2008/09 would be the year for mobile, and I quite honestly like to think that my prediction is slowly becoming true. Google has released Android (a software development language for building mobile applications FREE) into the T-Mobile network that is being used by the G1 phones. Unfortunately for Google, it *is* with T-Mobile... kind of like the "SAMS cola" of phone services. But still, it was a MAJOR win for mobile devs everywhere.
Then, once the rumors of Android in the wild were out, you started to see a huge hike in production of more finger-friendly keyboards for mobile phones, such as the new Blackberry Storm and the iPhone. Suddenly, mobile was coming back in a REALLY big way.
Now, I honestly think there are companies out there struggling to figure out what to do next. Personally, I think that answer is quite obvious: start building mobile applications. Blackberry is based on Java, so is Android. Android right now is not nearly as big as Blackberry, but I bet you will see it catching up to speed IF (and this is truly an IF) Google sticks with it's guns for continuing development.
What does this have to do with the future of Internet/Web? Everything. Once people start seeing that the market is out there for mobile, they will start wanting more applications like Facebook's awesome mobile app that helps connect them to not only their personal computing internet surfing, but also with their mobile surfing. You're going to see new Advertisement business plans aimed primarily at the mobile community, you're going to see huge leaps in interacting with our documents we normally would be able to maintain on our personal computers. You're also going to see OpenID finally start reaching the masses as mobile will be how they will try to finally sell it to the public. OpenID (a one-login for everything idea) has been sponsored and worked with by the biggest names (IBM, Microsoft, Google, etc), but the online community (for security reasons of course) just don't want one login to tie them to everything. But, if they can say "hey, this way you don't have to have 15 logins for your computer and 15 others for your mobile, just use one with OpenID", they'll have a big selling point...
More than anything else, you're going to see innovation!! Innovation that I've been DYING to see come back to the digital nerds of our planet! I mean, it excites me even RIGHT NOW at how much we can truly do if we just stop being lazy and get out there and do it! The technology is here, and it's just a matter of kicking ourselves in the ass and saying LET'S GO DO IT!
That next step is Mobile...
I've been a mobile advocate since I learned how to send and receive to my Sony Ericson Z500a about 3-4 years ago. Since then, I started following trends with the new Mobile Web Standards that came out in 2005/06. When the world started seeing that it was possible to design sites around phones, the cell companies started to see a drastic increase in sales. The problem though, was phones just didn't have the resolution, the processor power, nor any other great qualities that made home computers the best user experience for surfing the web. This caused many to think it was just another fad and that mobile web would eventually just go away.
But the happy fact is that it didn't go away, and it has actually started growing faster every single quarter. I think I predicted 2 years ago that 2008/09 would be the year for mobile, and I quite honestly like to think that my prediction is slowly becoming true. Google has released Android (a software development language for building mobile applications FREE) into the T-Mobile network that is being used by the G1 phones. Unfortunately for Google, it *is* with T-Mobile... kind of like the "SAMS cola" of phone services. But still, it was a MAJOR win for mobile devs everywhere.
Then, once the rumors of Android in the wild were out, you started to see a huge hike in production of more finger-friendly keyboards for mobile phones, such as the new Blackberry Storm and the iPhone. Suddenly, mobile was coming back in a REALLY big way.
Now, I honestly think there are companies out there struggling to figure out what to do next. Personally, I think that answer is quite obvious: start building mobile applications. Blackberry is based on Java, so is Android. Android right now is not nearly as big as Blackberry, but I bet you will see it catching up to speed IF (and this is truly an IF) Google sticks with it's guns for continuing development.
What does this have to do with the future of Internet/Web? Everything. Once people start seeing that the market is out there for mobile, they will start wanting more applications like Facebook's awesome mobile app that helps connect them to not only their personal computing internet surfing, but also with their mobile surfing. You're going to see new Advertisement business plans aimed primarily at the mobile community, you're going to see huge leaps in interacting with our documents we normally would be able to maintain on our personal computers. You're also going to see OpenID finally start reaching the masses as mobile will be how they will try to finally sell it to the public. OpenID (a one-login for everything idea) has been sponsored and worked with by the biggest names (IBM, Microsoft, Google, etc), but the online community (for security reasons of course) just don't want one login to tie them to everything. But, if they can say "hey, this way you don't have to have 15 logins for your computer and 15 others for your mobile, just use one with OpenID", they'll have a big selling point...
More than anything else, you're going to see innovation!! Innovation that I've been DYING to see come back to the digital nerds of our planet! I mean, it excites me even RIGHT NOW at how much we can truly do if we just stop being lazy and get out there and do it! The technology is here, and it's just a matter of kicking ourselves in the ass and saying LET'S GO DO IT!
Subscribe to:
Posts (Atom)
Posts
