Mike Bernat's Blog: PHP Cookies vs Sessions - The Breakdown
495793
In a recent post to his blog, Mike Bernat gets down to basics with one of the key pieces of functionality in PHP data persistence - cookies vs. sessions.   Knowing the basics of cookies and sessions is essential to any successful PHP programmer. It is useful to store pieces information on the users computer for later use. Things like when they last visited, language of choice, age, etc. Cookies and Sessions are the perfect solution to our needs.   He talks about both, including demonstration code to clarify some points and a chart at the end to compare their features, strengths, and weaknesses.
634435
Andrei Zmievski has posted something new to his blog today about a feature of PHP6 that's finally been hammered down - HTTP input (request) decoding.   There have been no fewer than 4 different proposals floated before, but this one combines flexibility, performance, intuitiveness, and minimal architectural changes, and has only a couple of small drawbacks. Let's take a closer look.   He details the functionality - what it is, what's been decided on, and the advantages of the method. The basic approach is a "lazy" one where PHP will only store the request when it comes in, no filtering or anything, until you want to do something with it (i.e. get it via $_GET, $_POST, etc). When the request for data is made, PHP looks at the encoding settings and formats the data accordingly.   Advantages he mentions for this method include removing the guess-work on PHP's part for which encoding the request is and that it removes some of the overhead by not processing the data until it's actually needed.
660571
DevShed is starting up a new series this morning with this new tutorial, part one in the creation of a simple blogging system using PHP and MySQL.   In this three-part tutorial we are going to be creating an open blogging system. We are also going to provide scripts that will make it possible to switch to a closed blogging system. This article, which is the first part, will cover the creation of the login scripts for a closed system.   They start with a definition, the difference between an open blogging system and a closed one (if users have to register or not). They start with the creation of the database to store the users in followed by the PHP code for the simple login page. It uses sessions to keep track of which user is logged in. Of course, where there's a log in, there needs to be a log out and they give the simple code for that. Finally, they include a "forgot your password" script to help users when they can't remember the info they'd signed up with.
415712
To set things right about a misquote on Slashdot, Zeev Suraksi has posted this long statement mentioning what he really said and a few more personal opinions.   I've just been misquoted on Slashdot, as if I said there are no security problems in PHP itself, and that I instead point my finger only at inexperienced developers. If you read the original article on Heise Security, you'll see that I have not said anything of the sort. [...] I believe this is the belief of most others on the security team, but I'm only speaking on behalf of myself and do not represent them.   He also covers five more points pertaining to the article and the situation:  Where the bugs/problems lie with problems in PHP Why there are security problems in web PHP applications Why the current security level can be partially blamed on the language itself An admission that yes, there are security problems in PHP And the track record the PHP developers have had in fixing these issues  There's much more than just these brief highlights here, so I encourage you to head on over and check out the full post for yourself.   There are some other opinions on the matter from a few others out there too:  cyberlot's blog Zend Developer Zone's post Tony Bibbs' blog
635724
In a new post on his blog, Christian Wenz mentions the latest results of the SANS Institute's Top 20 Internet Security Attack Targets list which both includes a new entry ("Users") and several mentions of PHP and PHP-related applications.   Of course you can debate how such a Top list came together and what the real value behind that is, but there are two specific points in this year's list that I found quite interesting.   There's two targets for the PHP community to worry about - sysadmin/hosting and things developers need to keep in mind. Items on these lists include:  Always test and deploy patches and new versions of PHP as they are released Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks If you use PHP, migrate your application to PHP 5.2 as a matter of urgency. Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks  You can check out the full information over on the SANS Institute website.
722744
On his blog, Ian Bicking has posted some of his thoughts on a positive look at PHP - what he thinks PHP has done right.   With the recent talk on the blogosphere about deployment (and for Django, and lots of other posts too), people are thinking about PHP a bit more analytically. I think people mostly get it wrong.   He points out that PHP, in essence, is a CGI-style execution and, in being so, makes it more flexible. Both sides, web and command line, can work with the language equally well. He also mentions the developer/administrator split he sees in PHP's structure and how the language facilitates it.
465600
Joshua Eichorn notes in a quick post that, due to a last minute change, he will be speaking at php/db|works this year.   He'll be giving two Ajax sessions:  Scaling with Ajax (Wednesday @ 10:15) Javascript Light and Sweet (Wednesday @ 14:45)    Check out the full listing schedule over on the php|architect site for complete details on the whos and whens of each day of the conference. And, of course, you can still sign up for the conference too!
247778
From the PHP-Coding-Practices.com site today, there's a new article that discusses some of the top security vulnerabilities that surround PHP applications.   PHP has allowed people with all sorts of backgrounds to put their ideas on the web. With several hundred million web pages programmed in PHP, security plays a big deal for us web programmers. In this introduction I will outline the most common security vulnerabilities in PHP scripts.   Topics include:  All Input is Tainted Cross-Site Scripting SQL Injection Code Injection Command Injection Session and Cookie Security Securing File Access   Each has their own explanation (including code where needed) that talks about what the issue is and a hint at its solution. This post will be followed by more tutorials that will focus on each of the topics in more detail with solutions to help solve and prevent them from happening in your application.
636915
Popular posts from PHPDeveloper.org for the past week:RefreshinglyBlue Blog: PHP vs Ruby - Practical Language DifferencesAndreas Gohr's Blog: Determine StumbleUpon RankingsPHP.net: PHP 5.2.4 ReleasedThe Bakery: Five New Posts - Custom Views, CSS, ViewInFile, ActsAs and Email ValidationPHPBuilder.com: File uploads made easyStefan Mischook's Blog: Turning on display_errors in WAMP - Video Tutorialphp|architect: Pro::PHP Podcast - Newscast for August 2007MT-Soft Blog: Creating a secure PHP production environment from Source CodeCommunity News: Andi Gutmans to Present at AjaxWorld 2007HowTo Forge: How To Set Up A Facebook RSS Feed Reader
345464
php|architect has a new note about a few PHP vulnerabilities:
489518
On his blog today, Alex Netkachov has posted a suggestion of how to combat a common issue facing PHP scripts - their memory usage.   PHP has a build-in garbage collector so you do not need to track the links on the objects, allocate memory for objects and delete them when they are not longer necessary. Things seem so perfect that developers do not even know that their scripts allocate a lot of memory until their server stops processing requests because of the out of memory error.   His example is the processing of a parent/child relationship tree. If not managed correctly, the variables being used could get out of hand quite quickly. Alex recommends the use of a "destructor" at the end of each iteration to help destroy variables and values no longer needed.
41064
Gerd Schauffelberger writes on the PHP-Tools Blog today about the contents of the latest issue from the German PHP Magazine, specifically an article covering the PEAR package HTML_AJAX.   This article's target is (1st) to give a brief introduction to AJAX and how things work from Javascript an PHP side in contrary. Also (2nd) I wanted to show that you actually don't have to muck around with a mess of Javascript (browser compatibility issues and such) because it's it is all done by the Joshua Eichorn's HTML_AJAX framework.    The article doesn't build up an entire application (as Gerd mentions) but it does provide you a good base to work from and gives you a good direction to head from to learn more about this powerful package.
633181
Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.   I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.   He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.   You can download the code here.
457664
In this post on the Zend Developer Zone, Cal Evans takes a look at an article published in a recent php|architect issue from Chris Hartjes about how several recent advancements in the PHP community have helped developers think more in "the Rails way" of development.   Chris does a good job of laying out his points. As with any article of this nature, you are going to agree with some of them and you'll disagree with some of them. However, to get to that point you'll have to consider all of them. That's really the point of the article; making developer sit back and think for a minute. It's well worth the read.   Cal also mentions some of the topics presented in the article including more conceptual ideas like "Convention Over Configuration" and "Rapid Should Mean Rapid".
416010
The IBM developerWorks site brings the community another great tutorial today, this time looking at the CakePHP framework and the creation of a simple application with it.    In "Cook up Web sites fast with CakePHP, Part 1: Adding related information and services", they build a sample application (Tor) from the ground up (installation guide and all) that will take in a username and password on a login page. Their goal is to show you how much time you could safe by using the framework over just the usual library-based (or procedural) programming methods.   You will need to be a bit familiar with PHP and the Model/View/Controller design pattern before you get started here, but if you have that down, you can just jump right in. You'll also either need to register with the site or log in with your account information to get to the good stuff.
464596
PHP isn't exclusively for Web pages. You can use it like Perl for cron jobs and other tasks.
211060
A few days back there was a post on the "The Codist" blog about why the author would never quite understand the appeal of PHP to the masses and some of his thoughts behind it. Well, there was such an outcry and response to his comments that he's written up another post on what he learned from comments made.   Clearly I touched a nerve. However I did learn a lot of things that you don't read in a quickly tutorial on PHP. The whole point of writing something is to get feedback, positive or negative, and hopefully learn from it.   He admits that his experience with PHP and its developers has been limited, so his perspective might have been thrown off a bit. He still holds to one thing from the previous article, though - that PHP just isn't for him.