PHP Magazine: Login Boxes Shouldn't Hurt
622987
Close on the heels of the SimpleTest 1.0RC1 release, is a new article titled "Coding a Login Box Shouldn't Hurt". Web sites can be fiddly to test, especially when it includes functionality like cookie handling and form filling. While manual testing is error prone and tedious, using a Web testing tool can automate the process, making development fast, accurate, and even fun. In this new article , Marcus Baker, helps you solve this tricky problem of authenticating users, by using test driven development.
723192
Here's what was popular in the PHP community one year ago today:Yet Another Web Development Blog: A PHP Developer Spends a Week with PythonZend Developer Zone: AJAX Chat Tutorial Pt 5: Javascript, Sending Chat Messages, Screen Name ChangesWebDevLogs: ClickHeat - PHP+JS heatmapTemplora.com: Basic PHP Script SecurityVinu Thomas' Blog: Modifying your MySQL databases to be UTF-8 compliantJeff Moore's Blog: PDO versus MDB2AnyExample.com: PHP password generationJason Palmer's Blog: Zip Code To LocationThe Bakery Blog: A gift for all to enjoySara Golemon's Blog: PHP-2006: A look backMatthew O'Phinney's Blog: Overloading arrays in PHP 5.2.0Davey Shafik's Blog: A Year in Review (2006)Jacques Marneweck's Blog: Smarty tip for including multiple javascript filesphp|architect: Final days of our iPod Training Promo!Alexander Netkachev's Blog: About Eclipse PHP IDE php.ini location
505235
Stefan Esser is trying to clear up some confusion in a new post to the PHP Security Blog today about his stand on enabling open_basedir on your PHP installation.   From time to time I get the question why I recommend enabling open_basedir and on the other hand call it a solution flawed by design. This is actually a good question, because the untrained PHP user might get a little bit confused about this and might believe that I change my opinion on a daily basis.   He talks about his reasoning - how it does it's job protecting PHP developers from being able to get to those file, but how it's also flawed with issues due to some 3rd party libraries that have their own problems.
345464
php|architect has a new note about a few PHP vulnerabilities:
670105
The Zend Developer Zone has posted two more handy security tips - one concerning file/directory naming and the other about input validation.   From the first tip:   Don't rely on obscure names to keep your application safe. You should always check permissions, test for vulnerabilities with testing tools and keep an eye on your log files for suspicious activity. When designing your applications and web sites though, don't make it easy for bad people to do bad things. Donât use default or common names for your files and directories.   And from the second:   It's a sad fact of life but users are evil. Users want nothing more than to find a way to exploit your application. As soon as you let your guard down and start thinking "I'm only selling small stuffed animals so how evil can my users really be?" you've lost the battle.   You can catch up on these and the other previous security tips on this page on the Zend Developer Zone website.
656053
PHPKitchen has an interesting post covering one of the banes of most web developers existance - the "back button problem".
620214
On Paul Jones' weblog today, there's a posting covering one of the banes of PHP life - form processing/handling.
390086
In another quick note from Chris Shiflett, there's a summary of php|works and some of the comments made about it:
22096
The Developer Tutorials blog has posted their "winner" of a list of things to do to keep you and your website secure:   When it comes to PHP security, you often think of input filtering, SQL injection prevention, XSS in user submitted content and so on. Well, forget about that. They're all pretty trivial compared to what I feel is by far the most important security issue of any web application. Read on to find out why.   Their number one thing to do to keep safe and secure? "Keep your systems updated." They point out that security a web site is one thing but securing the system that it runs on/has been developed on is another (and improperly patched, it could cause some huge problems).    Now, the best way to keep on top of potential vulnerabilities in your underlying systems is with updates. Sometimes, however, you need to go a little further. [...] Watching the web is also a good idea; major security vulnerabilities generally make it to the front page of Digg.
554043
Released today from PHP Magazine is their latest PHPBarnstormer - Issue #20.
259126
In an "interesting" post to The Codist blog, there's one developer's look at PHP and his confession that he'll never quite understand the appeal of the language.   How PHP can be so popular is beyond me; the whole sense of encouraging all of your html, code, bindings, javascript, even sql (as in the below example) into a single file is a nightmare.   He Goes on to talk about his experience with JSP versus PHP and some perspectives on how PHP lacks features he's used to or how other developers he's talked to had similar issues.   One thing that concerns me (and apparently several others in the PHP community) is that he keeps talking about procedural PHP code that's an "all in one page" kind of setup. Well, of course this can get messy quickly - that's no way to code anything, much less PHP. Organization means more than just breaking code up into chunks on your page (though it's a very low-level start). Plus, the sample code he provides is a joke - a PHP developer with a few weeks of experience could push out something 10x better.
704303
Matthew McCool has a few reminders for developers out there thinking of using Ajax in your applications - mainly to remember that it has the potential of adding another vulnerability to your application.   Consider a registration form built out of PHP. Any aspect of your script that accepts and processes data is a potential point of attack. If you add Ajax, what youÃ¢ÂÂre doing is increasing the complexity of the application and, by extension, introducing greater vulnerability. More points of entry equal a larger attack surface, and that means potential problems for your application.   He continues his login form example and mentions a few things you could do to help protect your application and its users (including using the escaping functions built in to PHP to help remove some harmful input).
291476
Matthew Turland, like many in the PHP community these days, has been pondering PHP6 and what it might mean to both the developers and to the language itself:   Be that as it may, as a user with about five years under his belt as of now who has seen all qualities of PHP code ranging from pristine to pedantic, a thought or two has crossed my mind on the subject of the latest upcoming incarnation of the language.   Specifically, he talks about some of the hot topics like namespaces, the mysqlnd driver, Unicode support, and named parameters. Overall, though, his comments are positive, looking toward a brighter future for PHP with this upcoming edition.
72073
Security is becoming a more and more popular topic among PHP developers, and Joseph Crawford has followed the trend and written up his own look at the way PHP handles session and session information as it relates to the security for both the user and the server admin.   One aspect that I dislike about the internal PHP sessions is that they are stored in files on the hard disk (usually /tmp/) by default. This means anyone with access to the machine has access to read the session data. I prefer to store my session information in the database to add an extra layer of security.   He looks at the pitfalls of using this kind of setup (among them, multiple users being able to use one IP) and a simple method for creating a custom sessions handler to replace PHP's built-in one. His example works with a local database to handle saving and retrieving the session information. And, to make things unique, he generates a "fingerprint key" for each user's information to serve as a unique identifier rather than handling it on the connection.
277894
Chris Hartjes has posted a tutorial about the creation of a simple user registration system in an application developed in the CakePHP framework. In response to the popularity of his other article on using CakePHP's Auth component, he's created a bit of code to answer some questions.   People have been having some questions about how the password is hashed and questions about a user registration system. Of course, the snarky response is "go and read the source for Security::Hash() and create some of your own code", but it is easier to just give people some code so they stop asking.   His example code extends the User object for the model, makes a controller with a register() method call and creates the username/password form for the user the enter in their information.
357182
In a new post to his blog, Chris Hartjes, spurred on by an article in the latest edition of php|architect magazine (covering protecting your code), has shared a few opinions starting with a certain paragraph near the end.   To start, I will focus on the paragraph above. What I get out of that is that if only your source was closed and hidden from prying eyes, it would not have bugs in it. Which is, of course, total nonsense. Code has bugs because it's open and they feel safer? There are two kinds of bugs: application bugs (which is the code I would write) and system bugs (in this case, bugs that that appear from PHP itself). I'm sorry, but there is nothing I can do if there is a bug in PHP that causes my application to crash except to point this bug out to the people who have the ability to fix it.   He goes on to talk more about how protection like this (the article talks about using the IonCube Encoder) will not stop someone if they're really determine to get at the code underneath the encryption. His only suggestion is to make an application good enough that people wouldn't want to try to steal it as much and would rather pay for their version.   Encode your stuff if you want, but be aware that the minute you choose to do that you are telling your customers "I don't trust you" and I have a hard time understanding a business model that assumes people are going to want to steal the stuff you sell.
696609
On his blog, Stoyan Stefanov takes a look at using on of the most popular pieces of PHP forum software out there - phpBB - and optimizing the front-end.   During this short workshop there will be no changes to the phpBB code, we'll create a new template instead, so that in case something bad happens, your board will continue to work normally. As an example, I'll use the bgcanada.com/phpBB2, the board I volunteer to administrate.   The tutorial is broken up into sections:   The plan New subdomains Creating a new template Moving CSS to an external file, merging Copying files to the new subdomains Serving gzipped content Turning ETags off Expires header Sysadmin summary   It looks like a lot of steps, but each section is relatively short and written well so as not to have more information than needed. In the end you'll have a simple template that uses Yahoo's 14 optimization rules to make things work that much faster.