Hacker News new | past | comments | ask | show | jobs | submit login

What you are talking about are core language decisions. Good developers have known how to work around register globals for years now, and it's not been a problem in any modern web app I've touched for the last 8 years (off the top of my head).

The language being used here has absolutely nothing to do with the output. You could substitute the PHP shell_exec calls for something similar in python, ruby or any other language. You should audit anything that hits your server. Using PHP doesn't meant it's more susceptible to vulnerabilities.




>Good developers have known how to work around register globals for years now, and it's not been a problem in any modern web app I've touched for the last 8 years (off the top of my head).

A good programming language lets a good developer to focus on writing code, not wrestling with bullshit decisions. YES, good programmers can write good and safe PHP code. But in the same way, bad or unexperienced programmers WILL and DO write awful code. The most recent example is OP's code. I've clicked on a few links that people replying to me have posted, and honestly, I'm glad I didn't spend any more time looking at it.

>The language being used here has absolutely nothing to do with the output. You could substitute the PHP shell_exec calls for something similar in python, ruby or any other language.

Like I said in previous comments, substituting PHP by Python or Ruby wouldn't improve the situation very much; I agree with that. The correct way to do it is to separate the data collection from the web interface. I think that should be common sense, and I fear that PHP is eroding that by making it very easy to do it "the lazy way" (fuck it, we'll use shell_exec on the web, what's the worst that could happen right?).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: