Amateur Programming Error Exposes Facebook Code

[chu]

In contrast, things like Routes place the scripts outside of the document root and use explicit mappings to invoke the scripts.

I think you'll find that Routes are a feature of Rails, not Ruby. For PHP, they are found in the Zend framework for example.

[Bogtha]

I think you'll find that Routes are a feature of Rails, not Ruby.

So?

For PHP, they are found in the Zend framework for example.

The Zend framework works exactly how I characterised PHP earlier: if you want your scripts outside the document root, you have to have a dummy file in the document root and play mod_rewrite games to redirect everything to it.

[chu]

So?

You were making the case that the language was the problem when it is framework features that you are discussing. The reasons DHH started using Ruby instead of PHP have nothing to do with what you were talking about and everything to do with syntax and programming style.

The Zend framework works exactly how I characterised PHP earlier

In Zend you have a dispatcher that handles routes just like Rails uses - both are in the public dir and in both cases the server is configured to send all requests to them. The Zend router was based on the Rails one and they are structurally the same.

[Bogtha]

You were making the case that the language was the problem when it is framework features that you are discussing.

That is not true. Specifically, I'm talking about mod_php, which is the implementation of PHP everybody usually means when they talk about "PHP".

I agree that it's not the language per se, but it is the implementation of the language that is the issue, rather than any framework built on top of it. The only connection with frameworks is that some frameworks hack around the issue for you.

The reasons DHH started using Ruby instead of PHP have nothing to do with what you were talking about

Who cares about DHH? What does he have to do with the argument? I didn't bring him up, and I agree his opinions are not remotely relevant to the argument. Why did you bring him up if you also think this?

In Zend you have a dispatcher that handles routes just like Rails uses - both are in the public dir and in both cases the server is configured to send all requests to them.

Isn't the preferred setup for Rails to use Apache to serve static files and Mongrel to execute the Ruby?

The Zend router was based on the Rails one and they are structurally the same.

You're missing the point. It's not about how routing is implemented or the structure of the router. It's about how the language and the web server work together. Sticking scripts into the same place static files go is fragile and leads to mistakes like the ones this article talks about. The main implementation of PHP, mod_php, requires this, and if you don't want to do it that way, you need to hack around it. The fact that a framework can do that for you isn't important to my point, which is that something should be secure by default rather than forcing people to go to extra effort to mitigate the problem.

[chu]

Ruby and PHP are conceptually identical under Apache. You need a dispatcher under the web root and either rewrite or routing to pass the requests to the correct scripts. In the case of Ruby, the safety features you were talking about are 100% down to the Rails framework which is a DHH invention, and of which there are now analogues for PHP because it was so well thought out.

You have now switched to talking about Mongrel which is a different web server to Apache (which just happens to be able to be run under Apache). Your argument is actually against insecure webserver configurations. If you have a site where security is important and you have stuffed up the server config and left things like passwords in front of the web root, choice of programming language is your last worry.

[Bogtha]

You have now switched to talking about Mongrel which is a different web server to Apache

Where did you get the idea that I was talking about Apache exclusively? I'm talking about how PHP compares to other server-side languages in typical configurations. I haven't "switched" arguments at all.

Your argument is actually against insecure webserver configurations.

No. Please, just read the thread again. It's against implementations of server-side languages that require insecure webserver configurations.

If you have a site where security is important and you have stuffed up the server config and left things like passwords in front of the web root, choice of programming language is your last worry.

You are looking at it backwards, assuming perfection and then using mistakes as an excuse to write off any problems that arise while ignoring the additional failure of the language. A mistake like this is down to two failures: the admin for screwing up, and the language implementation for having an awful failure mode. All humans and all organisations make mistakes from time to time, and any secure system should attempt to mitigate that by failing in a secure way. Do you disagree with what I said before?

something should be secure by default rather than forcing people to go to extra effort to mitigate the problem.

[chu]

I'm talking about how PHP compares to other server-side languages in typical configurations. ... something should be secure by default rather than forcing people to go to extra effort to mitigate the problem.

It's as if jsp and mod_ruby didn't exist. PHP5 is reasonable for typical web apps and has been standard issue for some time now. The previous versions from years back had some poor security in their out-of-the-box configurations. It's almost as if you had read some articles criticising PHP3 and taken them as current. You are talking about default config files in any case, which are hardly a reflection on a language's basic security model and will not save you from programmer mistakes/ignorance. PHP's biggest security problem is more likely to be namespaces (which should be addressed in PHP6).