In Developer.com's latest article, they continue their series (part 1) of working with PHP5's object system to create an abstraction layer, specifically a database layer.

They start with a look at some of the "accessibility modifiers" that PHP5 has to offer - like private or public - in it's object model. They define them in the context of their database class as well, demonstrating how both variables and classes can be marked this way. After this, it's all about the code, looking first at preparing the SQL query, then validate the SQL before sending it off to the last step - executing the query and fetching the results (if needed).

In Developer.com's latest article, they continue their series (part 1) of working with PHP5's object system to create an abstraction layer, specifically a database layer.

They start with a look at some of the "accessibility modifiers" that PHP5 has to offer - like private or public - in it's object model. They define them in the context of their database class as well, demonstrating how both variables and classes can be marked this way. After this, it's all about the code, looking first at preparing the SQL query, then validate the SQL before sending it off to the last step - executing the query and fetching the results (if needed).

Greg Beaver has posted some tips he has (with a few updates along the way) about protecting your MySQL username and password in a PHP script, hiding the plain-text version from would-be attackers.

Two days ago, I gave a talk at the University of Nebraska-Lincoln's computer science department colloquium on open source. At the reception preceding the talk, one of the students asked if there was a good way to protect the user/password of his MySQL scripts. This is an issue I have never run up against because we have a unique IP on the webhost, and it doesn't matter whether someone knows the user/pass, they can only connect directly from that host (and if someone can hack into the host, I doubt the database is the only thing that will be compromised).

The dilema was caused by the shared hosting of the students' sites and the plain-text storage of their database user/pass in a Wordpress file. Greg suggested two methods, one where each user gets their own Apache space, and another where the password is stored in a read-only file that just the server has access to.

Chris Shiflett came back with a comment, however, about another, more secure mthod - using an .htaccess that only the user can work with (and can change at any time) containing and setting Apache environment variables the script could then pull.

Greg Beaver has posted some tips he has (with a few updates along the way) about protecting your MySQL username and password in a PHP script, hiding the plain-text version from would-be attackers.

Two days ago, I gave a talk at the University of Nebraska-Lincoln's computer science department colloquium on open source. At the reception preceding the talk, one of the students asked if there was a good way to protect the user/password of his MySQL scripts. This is an issue I have never run up against because we have a unique IP on the webhost, and it doesn't matter whether someone knows the user/pass, they can only connect directly from that host (and if someone can hack into the host, I doubt the database is the only thing that will be compromised).

The dilema was caused by the shared hosting of the students' sites and the plain-text storage of their database user/pass in a Wordpress file. Greg suggested two methods, one where each user gets their own Apache space, and another where the password is stored in a read-only file that just the server has access to.

Chris Shiflett came back with a comment, however, about another, more secure mthod - using an .htaccess that only the user can work with (and can change at any time) containing and setting Apache environment variables the script could then pull.

Some PHP developers out there are very protective of their code for one reason or another. Sometimes it's a matter of their hard work, slaving over a keyboard for hours and hours to get it exactly right. Then there's the other reason - money. Of course, no matter what your situation, a new post from Justin Silverton might help you narrow down the encoder software field a bit.