The other day, an article popped up in my feed reader that had a very interesting title (to me at least), Simple and Secure Login Script. As usual, I decided to click the link and give the article a read. Not overly shocking was the fact that I didn’t find the content of the article to be, how shall I say this…, overly factual. It’s not really a “tutorial”, but more of a “here’s some code that’s secure”. A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few “really bad practices”).

So, rather than write a “rant post” about the code, I’ve decided to take another tactic. In this article, I’m going to walk you through my process for performing a security code review. Inline with the review, we’ll take note of any issues that we do find, and number them. Then at the end of the review, we’ll go over each one and look at potential mediation that we can apply and how to fix the issues.

Today’s IDEs (Integrated Development Environments) provide a lot of features that make development significantly easier. From error checking and debugging to intelligent syntax highlighting and refactoring, there are a significant amount of time saving features available. One of these commonly loved features I have disabled, and found it has made my life easier as well as the code I write better. The feature I am speaking of is autocompletion…

The upcoming release of PHP 5.4.0 includes a plethora of new features, including Traits. While I do believe this is a great feature with great possibilities, I also fear that it may fall into the category of often-abused-features such as eval(), goto, constants, the @ operator, class inheritance and regular expressions.

Today an article popped into my feed reader that raise my eyebrows. The article’s title is “Building Secured Web Applications Using PHP - The Basics“. The summary of the item looked interesting, so I decided to open it up…

What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject…

I have always been intrigued by projects such as PHP.JS. To be completely honest, it’s not because I though they were “neat” or “innovative”, but because they have always made me ask myself “Why would someone seriously want to do something like that?!?!?”… Let me try to explain my standpoint.

While working on testing out my new Cryptography library (appropriately called PHP-CryptLib), I ran into a rather interesting problem. How do you unit test a method that interacts with the file-system? Traditionally, this problem has been solved by either not testing the method or creating temporary directory structures, testing, and then deleting the temporary directories. There has to be a better way. And as it turns out there is!

I recently read a post entitled Dependency Injection: An Analogy, and I think it does a pretty good job explaining two of the types of Dependency Injection. I really like the theme, and feel it really brings down the topic of DI to easy to understand language. The only problem with it that I can see is that there are actually 4 flavors of DI available to us. The other two flavors aren’t even touched in that post. So let me expand on that theme a bit here (Borrowing the same core analogy base from that post):

Quite often we see people talking about the best way to approach a problem. Usually this involves taking a relatively simple concept and making it fairly complicated to make it as flexible and maintainable as possible. While I’m all for maintainability, I think that sometimes we miss the point that it all depends on context. It seems like most people don’t understand the difference between good and good enough.

Part of being a developer is making design decisions based on conflicting goals. Our job is to choose the line that’s appropriate based upon our experience and the needs of what we’re doing. But there-in lies the problem: How do we know where that line really is? How do we know when we’ve actually reached the point of good enough?