The slides for Securing PHP Sessions are now online. This was my last talk, and I'll have pictures and conference comments up soon.
About the Author
Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.
All posts for Jul 2004
Display posts by year and monthSkip this section and jump to the main content
My OSCON tutorial, PHP Security, was a big hit. The workbook for the tutorial is likely the most complete source of PHP security information and best practices available (until my book, PHP Security, is published).
Here it is: php-security.pdf (248 KB, 55 pages). I hope you find it helpful.
I'll be spending this week in Portland, Oregon at the O'Reilly Open Source Convention.
I'm giving a talk on the PHP track called Securing PHP Sessions that should be interesting. I'll be focusing on topics such as session fixation and session hijacking, and I'll demonstrate some methods to complicate these attacks and make your session mechanism a bit stronger.
I'm also giving a talk on the Security track called Foiling Cross-Site Attacks. I'll be discussing cross-site scripting and cross-site request forgeries. All examples are in PHP, although the talk is applicable to all Web developers.
Lastly, I'm teaching a tutorial, PHP Security. I have put a lot of work into preparing for this, and I think it's going to be a lot of fun. The workbook itself is 55 pages, and I plan to make a PDF of that available after I put my slides up.
I hope to see some of you there.
I am happy to be a member of the Zend PHP Education Advisory Board, the group that "has established the curriculum criteria necessary to demonstrate expertise in PHP." In addition to authoring some of the examination questions, I also now know what a psychometrician is. I think I even spelled it correctly.
I am a coauthor of the Zend PHP Certification Study Guide, which will be available within a week or two. If you want a guide that teaches you everything you need to know to pass the examination, this is the book for you. I think this is a particularly good book, because it covers a wide range of topics, and because each topic is explained by an author chosen for his expertise in that particular topic. There are also practice questions at the end of each chapter to help you determine whether you have sufficiently learned the material.
Opinions about certifications are mixed, but no one can deny that this is another step forward for PHP. Add in the release of PHP 5 and the recent news that PHP is one of the five most popular programming languages, and I'd say this has been a very good week for the PHP community.
php|works is a new conference hosted by the folks at php|architect, and it is being held in Toronto, Canada from 22 Sep to 24 Sep. In addition to the session schedule, there is some handy information on convincing the boss.
Hopefully I'll have PHP Security written in time for some of these. :-)
After visiting again, I see that many of the PHP blogs that were missing have been added. It still uses blog titles rather than the names of people, but Christian promises to think about it. I much prefer the names, and it seems that Planet Apache and FOSS Planet feel the same way.
There has been a lot of discussion lately about scalability, brought about by Friendster's move to PHP. Once again, I am amazed at how many people don't understand what scalability means (even though I'm glad to see fewer and fewer people misspelling it). Scalability means "How well a solution to some problem will work when the size of the problem increases" (from Dictionary.com). This is interpreted in drastically different ways, and you can find my interpretation in What Is Scalability?.
Before I continue, let's look at some of the clueful comments from Joyce Park's blog entry:
Rasmus Lerdorf writes:
Scalability is gained by using a shared-nothing architecture where you can scale horizontally infinitely. A typical Java application will make use of the fact that it is running under a JVM in which you can store session and state data very easily and you can effectively write a web application very much the same way you would write a desktop application. This is very convenient, but it doesn't scale. To scale this you then have to add other mechanisms to do intra-JVM message passing which adds another level of complexity and performance issues. There are of course ways to avoid this, but the typical first Java implementation of something will fall into this trap.
PHP has no scalability issues of this nature. Each request is completely sandboxed from every other request and there is nothing in the language that leads people towards writing applications that don't scale.
Harry Fuecks writes (in response to someone citing performance benchmarks to support a scalability argument):
But performance != scalability.
Joyce Park writes (in response to someone suggesting that Friendster's Java developers must have been sub-par):
1) We had not one but TWO guys here who had written bestselling JSP books. Not that this necessarily means they're great Java devs, but I actually think our guys were as good as any team.
2) We tried rewriting the site in Java twice, using MVC and all available best practices. It actually got slower. Anyway, what does MVC have to do with speed or scalability? I thought it was a design cleanliness and maintainability thing.
3) We tried different app servers, different JVMs, different machines.
4) Anything that money could do, it did.
There has been a lot of discussion elsewhere, too. Harry Fuecks explains that The J2EE guy still doesn't get PHP and discusses Why PHP Scales. Harry understands what scalability means and takes the time to try to it explain it to everyone else. If you have read The PHP Scalability Myth or think that scalability is a measure of performance (or both), please take the time to read what Harry has written.
Jeff Moore, in The PHP scalability saga continues, writes:
I think I'll end this post with heresy. The field of web development seems to have a mental model of application development forged from the dot-com boom era. We operate with the vision that our applications are going to experience exponential usage growth. Perhaps this leads to an unhealthy focus on scalability in web applications versus other requirements. Perhaps this also leads us to employ optimizations prematurely before we can even understand their impact or even have a need for them. Perhaps these premature optimizations even hurt scalability and performance and needlessly complicate our applications.
Perhaps the Java Culture is more infected with "dot-com-itis" than the php culture?
Technical details aside, I think PHP can be made to scale because so many people think that it can't. This skepticism means that people buy into the fact that it takes hard work and intelligent design to make a PHP-based system work right. 'Intelligent design' doesn't mean adhering to MVC or design patterns, writing OO code or assembler. It means looking at your system as a whole, figuring out what it needs to do, and then devising a plan for doing that as cheaply as possible. The critical bit, of course, is that you need to put that sort of work into any large architecture; PHP doesn't magically scale 'naturally', but neither will planting a Java Bean in your backyard create a magic scalable beanstalk.
His entire "answer" is very informative, even if most of it is obvious. Sometimes what people need is for someone to stand up and state the obvious, and I think now is such a time.
Of course, there are plenty of people who aren't as clueful as Harry and George. Unfortunately, it's difficult to know who to listen to. John Lim says "High Performance, High Scalability PHP is a Lie". I assume that he just wanted a nice headline, but his statement couldn't be further from the truth.
Last October, I briefly answered the question What Is Scalability?. Perhaps my use of Big O notation wasn't the best approach, since most people who truly understand my point likely already know what scalability means. A simpler explanation might be better. In fact, we need to eliminate computers from the explanation altogether, because that alone seems to confuse people.
Compare a truck and a tractor (hypothetically). To simplify our comparison, let's assume that both have the exact same towing capacity (this might be unrealistic, but such is the beauty of hypothetical situations). With no load, the truck has a maximum speed of 125 mph (about 200 kph), and the tractor has a maximum speed of 15 mph (about 25 kph). With a load equivalent to their maximum towing capacity, the truck has a maximum speed of 45 mph (about 70 kph), and the tractor has a maximum speed of 10 mph (about 15 kph). Which scales better? If you think the truck does, you're wrong. Although the truck is faster in all cases (loaded, it is even faster than the tractor with no load), it slows down the most under load, proportionately.
If you're only concerned with speed, you should choose a Ferrari Modena rather than decide between the truck and the tractor. If you're only concerned with scalability (which is highly unlikely), you should choose the tractor. If you're concerned with the best combination of speed and scalability, the truck is a good choice.
So how does scalability apply to the Web? First, you should ask yourself whether the Web's fundamental architecture is scalable. The answer is yes. Some people will describe HTTP's statelessness in a derogatory manner. The more enlightened people, however, understand that this is one of the key characteristics that make HTTP such a scalable protocol. What makes it scalable? With every HTTP transaction being completely independent, the amount of resources necessary grows linearly with the amount of requests received. In a system that does not scale (where "does not scale" means that it scales poorly), the amount of resources necessary would increase at a higher rate than the number of requests. While HTTP has its flaws (the proper spelling of referrer being one), there's no arguing that it scales, and this is one of the things that made the Web's early explosive growth less painful than it would have otherwise been.
The present discussion is about developing Web applications that scale well, and whether particular languages, technologies, and platforms are more appropriate than others. My opinion is that some things scale more naturally than others, and Rasmus's explanation above touches on this. PHP, when compiled as an Apache module (mod_php), fits nicely into the basic Web paradigm. In fact, it might be easier to imagine PHP as a new skill that Apache can learn. HTTP requests are still handled by Apache, and unless your programming logic specifically requires interaction with another source (database, filesystem, network), your application will scale as well as Apache (with a decrease in performance based upon the complexity of your programming logic). This is why PHP naturally scales. The caveat I mention is why your PHP application may not scale.
A common (and somewhat trite) argument being tossed around is that scalability has nothing to do with the programming language. While it is true that language syntax is irrelevant, the environments in which languages typically operate can vary drastically, and this makes a big difference. PHP is much different than ColdFusion or JSP. In terms of scalability, PHP has an advantage, but it loses a few features that some developers miss (which is why there are efforts to create application servers for PHP). The PHP versus JSP argument should focus on environment, otherwise the point gets lost.
I actually disagree with George's statement, "PHP doesn't magically scale 'naturally'". Of course, I understand and agree with the spirit of what he's trying to say, which is that using PHP isn't going to make your applications magically scale well, but I do believe that PHP has a natural advantage, as I just described. Rasmus seems to agree with me, and George might also agree, despite his statement.
I think PHP scales well because Apache scales well because the Web scales well. PHP doesn't try to reinvent the wheel; it simply tries to fit into the existing paradigm, and this is the beauty of it.
- Automatically converting PDF to Keynote
- from Rob Allen
- When debugging doesn't suck: beautiful errors
- from Alessandro Nadalin
- Copy to Clipboard from Command Line
- from David Walsh
- How to Skylark – the class
- from Kristina Chodorow
- What to do when an employee moves overseas
- from WonderProxy
- Understanding Stacked Bar Charts: The Worst Or The Best?
- from Smashing Magazine
- JPEG Compression with Guetzli
- from David Walsh
- Invisible CAPTCHA
- Announcing the First SHA-1 Collision
- Image-to-Image Demo
- Is Google Maps Trying to Be a Social Network?
- How to Run for Your Local School Board
- Straight Pole Curved Hole Optical Illusion Explanation
- GitHub’s Post-CSP Journey
- The Line of Death
- Across the USA by Train for Just $213