I'm in Montreal this week for PHP Quebec. My first talk, PHP Security Workshop, went really well. I learned from some of the other attendees that I rasmussed the other talks being given at the same time. It's nice to see security getting more and more attention within the PHP community.
I visited St. Joseph's Oratory yesterday:
Adam recommends visiting the old city, so I hope to find time to do that as well.
I'm sitting in Ilia's talk right now. He's speaking about web services, and he's using the IPIP protocol in some of his examples. IPIP is Ilia's Proprietary Internet Protocol. :-)
Like Christian, I got an email this morning about ApacheCon:
The following sessions have been selected and
(1179) 'Testing PHP with Perl'
(1180) 'PHP Security'
(1181) 'PHP Security Briefing'
PHP Security is a 180 minute tutorial that I'll be giving. Although I've given a tutorial of the same name and length for past OSCONs and ApacheCons, all of the talks I'm giving this year are going to be completely new talks, this one included. I also plan to retire my use of pres2 in favor of Keynote.
Testing PHP with Perl is the talk I'm most excited about. Although Adam and I helped select the PHP talks, I didn't rank my own, and I was worried that this talk wouldn't make the cut (testing is not yet a popular topic within the PHP community). I'm sorry to say that Geoff won't be making the trip to Germany with me, but the talk will surely benefit from his guidance. With any luck, I'll also be able to discuss using Apache-Test and SimpleTest together.
PHP Security Briefing is a 60 minute talk that will cover some of the same topics as Mastering PHP Security.
I've never been to Germany, so I'm looking forward to the trip. I also look forward to finally meeting some people in person (such as Ivan and Georg), meeting new people, and hanging out with old friends.
I hope to see you there.
The talk I gave as part of php|symphony was a big hit. I got more positive feedback from that talk than any of the talks I've given in the past. I think it's due to a combination of the refinements I've made in the way I present this topic (PHP security) and the fact that I've switched to using Keynote for all of my talks now. Having great content is important, but having it look great doesn't hurt.
For those that missed it, there is a repeat of Mastering PHP Security on Wed, 06 Apr. If you sign up by Thu, 31 Mar, it's only $40. Not a bad deal. :-)
Do not store your PHP includes in document root. This is a terrible practice. Here is just one reason why:
Don't recommend naming PHP includes with a .php extension. Don't recommend including code in PHP includes that prevents direct requests. Don't recommend the following for denying requests for .inc resources:
Deny from all
The problem is not that these techniques are bad, but rather than they are neither optimal nor sufficient. If you employ these techniques, do so only to adhere to the principle of defense in depth. If you're only going to implement one safeguard, choose the best one.
Do not store your PHP includes in document root. There are no exceptions. There are no excuses.
For those who don't visit the phpsec.org site frequently enough to notice, there is now a [phpsec-news] mailing list. The announcement explains its purpose:
On 01 Apr 2005, the PHP Security Consortium will begin to offer a monthly newsletter. All PHP developers concerned with security and the affairs of the PHP Security Consortium are encouraged to subscribe to the [phpsec-news] mailing list. This is a very low volume, moderated list.
The monthly newsletter will include such things as new additions to the library, new articles, project updates, and related news.
Because several people have requested it, we will soon be offering feeds as well, and newsletters will most likely be made available on the web site.
If you have news that you think is of interest to security-conscious PHP developers, please don't hesitate to contact us.
The new issue of php|architect just came out, and this month's Security Corner topic is magic quotes. In this article, I explain why the magic quotes directive should always be disabled. Because I often see people cite security as a reason to enable magic quotes, I felt that it was important to correct this misconception.
Personally, I would like to see magic quotes deprecated and eventually dropped from future releases of PHP.
In next month's issue, I might explain why BBCode is worthless. :-)
Thanks very much for all of the support I have received from the PHP community. It looks like Brain Bulb is off to a good start. I'd like to particularly thank those who helped publicize the announcement:
I've received many queries in the first few days, and most of them have been about the PHP security audits. Here are a few of the most common questions and answers (a real FAQ, not a marketing one):
- Q: Can I get an estimate?
- Q: How much does an estimate cost?
A: Estimates are free.
- Q: How long does the audit take?
A: The duration of the audit depends upon many factors. For an application with a clean design, an audit takes about one week per 5,000 lines of code.
- Q: What is your fee?
A: We offer two types of billing structures: hourly and fixed-fee. These are essentially the same, except that a fixed-fee audit has a cap. For full audits, the fee is based on an hourly rate, but it is guaranteed to be within twenty percent of the estimate.
Another common question is whether I am hiring. The answer is no, at least not in the traditional sense. I plan to actively seek out developers that I want to hire rather than the other way around. The best way to get noticed is to contribute to the PHP and open source communities. Selfless contributions reflect well upon your personal character and work ethic.
Update: More community support:
I've been answering questions lately on the SitePoint forums - PHP, Advanced PHP Programming, and Web Security.
One topic really caught my attention - How many actually use unit testing?. No, it wasn't the grammatical error that caught my eye but rather the fact that unit testing was being discussed on a PHP forum.
While reading the topic, I realized that there were many PHP developers using SimpleTest. Feeling like the black sheep, I mentioned my admiration for Apache-Test. I also tried to surmize why it isn't as popular in the PHP community as it is in the Perl community:
I'm not sure whether the average PHP developer would feel comfortable using it. Its userbase has traditionally been C, Perl, and mod_perl developers writing Apache modules and web applications that utilize many of the Apache API's hooks, etc. These people are comfortable on a command line and are writing some pretty complex code that needs the level of testing purity provided by Apache-Test.
When asked for an example test, I pointed readers to the Apache-Test demo that Geoff and I created last year.
Marcus Baker, author of SimpleTest, replied with the following:
Would you be willing to help with getting SimpeTest working with Apache-test?
I replied that I'd be happy to, and now Marcus and I are going to be working together to make SimpleTest output a TAP compliant protocol.
As Geoff is fond of saying, "Build it, and they will come." Well, hopfully Marcus and I can help make all of Geoff's work worthwhile, and hopefully the PHP community can catch up with the Perl community in terms of testing.
I am very happy to announce the launch of Brain Bulb, a company that I've been planning for over a year. It's purely a PHP consultancy, and this is a reflection of my faith in PHP's promise. While it offers a few services already available elsewhere (development, PHP training, etc.), there are a couple of services that are not so common:
Of course, as PHP continues to grow and mature, you can expect to see more and more of these types of services being offered. I think it's only a matter of time. I hope Brain Bulb can help lead the way.
Thanks to everyone who has helped me reach this point. You know who you are.
My visit with MusiChristian.com went well. I spent three days learning more about their business and their existing technical infrastructure, and I was able to offer some general recommendations concerning their future.
I am now writing a technical specification for them, a project that Patrick Reilly and I are collaborating on. There are some interesting new ideas concerning this particular task that try to address the fact that many traditional methods are too difficult for clients to understand. If your client can't make sense of the specification you write, it's less likely to accurately reflect the client's needs and desires, and this can be very problematic during development.
I don't necessarily agree that interface design is a complete substitute for a technical specification. However, I do think it's very beneficial to accompany technical details with example interfaces and to use them as a guide. Not only is this likely to be a more comfortable approach for the client, but it also has the added benefit of forcing you to consider the application from a user's perspective.
Zend just announced their PHP Conference and Expo. Unfortunately, they have chosen the same week in which OSCON Europe is already scheduled. OSCON is always my favorite conference each year, and I've been looking forward to OSCON Europe since I first heard about it.
This scheduling conflict may not affect many people (OSCON will be in Amsterdam, while Zend's conference will be in California), but I'm sure there are others in the PHP community who are in the same position. Perhaps openconf can help us avoid these situations in the future.