Live data from Hacker News

PHP 7 deployment at Dailymotion

engineering.dailymotion.com

131–140 of 166 posts

Re: PHP 7 deployment at Dailymotion

#131
post #43

Earlier quoted context omitted.

In all seriousness, shouldn't all the frameworks just have some validation built in? Being that this is such a "global" WTF problem. I would love to be able to say ini_set('sanitize_rest', true) and deal with errors that might result from that knowing at least the strings are safe. Or have functions like sanitize_string($str) and have the documentation encourage it everywhere. I mean, aren't we all just implementing…

A one-size-fits-all cannot work. Ever. For an SQL-based DB (i.e. where the data mixes with the logic in the query) you should be using parameterised queries anyway. For general data sanitisation/validation you should look at the filter_* functions.

What does this nonsense reply even mean? Nobody is talking about one-size-fits-all. People are talking about mitigating some stupid default behavior in a language. The suggestion "You're doing it wrong" just feeds into his point (that you can even get something this straightforward wrong in the first place indicates, maybe, you should put a fence there to warn people).

Programmers have so much stockholm syndrome it's unbelievable.

Re: PHP 7 deployment at Dailymotion

#132
post #67
post #12

I used to run one of my site (25K unique visitors a day) on PHP 5.3, when HHVM came out with stable version I shifted to HHVM and I had similar experience. Now I am running it on PHP 7 and I have to say I am more than happy with results. As much as PHP is not cool for today's developers it has served on some really high traffic sites and stayed useful even with the test of time. P.S. Now I wish somebody just implemen…

HHVM implements a good async I/O system [0] and has the ability to run HTTP. [0] https://docs.hhvm.com/hack/async/introduction

This seems interesting hopefully someone will pick this up and make even the mysql_* and other sync functions async too. This could be final nail in the coffin.

Re: PHP 7 deployment at Dailymotion

#133
post #131

Earlier quoted context omitted.

A one-size-fits-all cannot work. Ever. For an SQL-based DB (i.e. where the data mixes with the logic in the query) you should be using parameterised queries anyway. For general data sanitisation/validation you should look at the filter_* functions.

What does this nonsense reply even mean? Nobody is talking about one-size-fits-all. People are talking about mitigating some stupid default behavior in a language. The suggestion "You're doing it wrong" just feeds into his point (that you can even get something this straightforward wrong in the first place indicates, maybe, you should put a fence there to warn people). Programmers have so much stockholm syndrome it's…

> Nobody is talking about one-size-fits-all.

> I would love to be able to say ini_set('sanitize_rest', true) and deal with errors that might result from that knowing at least the strings are safe.

How is a magic ini setting to "make Strings safe" not a one-size-fits-all?

> People are talking about mitigating some stupid default behavior in a language.

What stupid default behaviour? Giving you data as its received and tools to validate/sanitize it as required?

Re: PHP 7 deployment at Dailymotion

#134
post #72
post #56

Earlier quoted context omitted.

PHP has already tried automatic sanitization with magic_quotes_gpc, and the results were far from secure. It is not possible to have a single sanitize() function that renders a string safe for every possible context, and to try to provide one results in nothing but complacency and false sense of security. Escaping for SQL is different from escaping for HTML, and even if you escaped a string for both, some idiot is go…

Right. I absolutely get this argument, except, the alternative to idiots misusing the tools is for those same idiots to start with no tools! And they're going to somehow implement and upload what they're building anyway...

Php has an entire extension devoted to sanitising and validating input data.

It can't be a simple on/off because php can't guess what your inputs are or what you want to use them for.

Re: PHP 7 deployment at Dailymotion

#135
post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

$_POST used to get user input in a Laravel controller? That's a sure sign to run away from that codebase.

Re: PHP 7 deployment at Dailymotion

#136
post #129
post #128

Earlier quoted context omitted.

But what is the reason why I would look back at PHP, when there have been better alternatives available for quite a while now?

I'll be honest I don't really care what languages people use, not my place to convince you back. Just saying there's quite high chances PHP has changed at least a tiny bit over the past 12 years

I started using PHP when it was in version 3 and still use it occassionally. It has changed, but not considerably. The function naming is still a mess (backwards compatibility), arrays are completely inappropriate (naming them "bags" would be better), some decisions were so baffling (safe mode and magic quotes, superglobals, square brackets for arrays...) that I simply don't trust PHP to ever get better.

But there was a reason for experienced developers to use it - hosting. You could write a web app, ftp it somewhere and it would just work. There was no other platform aside from asp which would offer that. Nowadays this doesn't matter much, but 10 years ago it was great.

As a language though? Ugly. Just plain ugly.

Re: PHP 7 deployment at Dailymotion

#137
post #129

Earlier quoted context omitted.

I'll be honest I don't really care what languages people use, not my place to convince you back. Just saying there's quite high chances PHP has changed at least a tiny bit over the past 12 years

I started using PHP when it was in version 3 and still use it occassionally. It has changed, but not considerably. The function naming is still a mess (backwards compatibility), arrays are completely inappropriate (naming them "bags" would be better), some decisions were so baffling (safe mode and magic quotes, superglobals, square brackets for arrays...) that I simply don't trust PHP to ever get better. But there wa…

I get safe mode, magic quotes and superglobals - but don't most languages use square brackets for arrays?

It certainly doesn't seem like a controversial thing to do.

Re: PHP 7 deployment at Dailymotion

#138
post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

Pro tip - first thing when you start a PHP project:

- move all superglobals to your private vars

- only allow access to these vars through your special functions which REQUIRE from programmer to specify type and validation / sanitization (regex for strings, min/max for numbers,...)

Make it difficult for programmers to use unsanitized vars and you will have much more secure code.

Not sure why no frameworks (that I know of) do this, but fortunately it is easy to add this.

Re: PHP 7 deployment at Dailymotion

#139
post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

Agreed, at Amazon you are allowed to use any programing language except for PHP for this very reason, it is the least secure. PHP is officially banned as a language.

Just curious, is this documented publicly anywhere?

Re: PHP 7 deployment at Dailymotion

#140

Earlier quoted context omitted.

> There's absolutely NOTHING wrong with having $_POST['whatever'] inside a controller as long as you're doing proper checks. The last part is why this is a problem. The truth is that programming is simply too difficult a task for human beings. Software is so complicated with so many moving parts that it is impossible for anyone to understand all the details of even the simplest piece of code. This is why we have oper…

> The last part is why this is a problem. $_POST isn't the problem. The scope of the variable isn't the problem. You've realized this, too, and that's why you're shifting the argument to one about typing instead of superglobals-are-bad (typing and scope are obviously independent features). > You want to reduce the number of things you have to think about to the absolute minimum The net effect of type systems seems to…

> typing and scope are obviously independent features

You might want to read about effect systems

http://rtpg.co/2016/07/20/supercharged-types.html

(it might not be the best blog post on the subject theory, but I think it's a nice practical example)

Post reply on HN