Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7 deployment at Dailymotion

engineering.dailymotion.com

Post reply on HN
Print view View original

81–90 of 166 posts

Re: PHP 7 deployment at Dailymotion

#81

Post by stephenr »

nikcub wrote: 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…

> http://cookbook.hacklang.org/recipes/get-and-post/

The fact that their "recipe" relies on one file being run in "non-strict" mode for it to work at all is very telling about how short-sighted this "vision" to remove superglobals is.

Even if you went the whole hog, and removed $_GET, $_POST etc. You force users to use filter_input() to get variables. (Why doesn't the Hack "recipe" do this anyway?)

Now tell me how you access a a structured POST body. e.g.

    foo[bar]=baz&foo[baz]=bar
Oh. Right, you can't. Because filter_input only returns scalars.

If you remove $_GET and $_POST people will just do the equivalent in the new construct:

    $query = "SELECT * FROM username_list WHERE username='" . filter_input(INPUT_POST, 'username') . "'";


    $query = "SELECT * FROM username_list WHERE username='" . $myFancyPostObject->getString('username') . "'";
The PHP developers who understand why using raw untrusted input is dangerous are already using the facilities provided to make the input safe for use, in some cases built around access to $_GET and $_POST.

The PHP developers who are already using raw untrusted input in dangerous ways will simply find new dangerous ways to use the data.

Re: PHP 7 deployment at Dailymotion

#82

Post by [deleted] »

nikcub wrote: 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…

[deleted]

Re: PHP 7 deployment at Dailymotion

#83

Post by Moru »

tedmiston wrote: post #58
skrebbel wrote: post #53

Earlier quoted context omitted.

If you have no idea, why bring it up?

Often times other people here do have a different perspective. I also found it very distracting from reading the post.

This view is pretty common for people reading their first language written by someone using their second or third language. This comes people that just isn't as good at writing and expressing themselves. This does by no means make their thoughts less valuable. Sometimes you just have to open your mind to other people even though the words come out in the wrong order.

English is not my first language either but I don't write "I'm sorry for my mistakes, english is not my first language" because that should be pretty obvious. And if it's not obvious, there is no need to say it, right?

Re: PHP 7 deployment at Dailymotion

#84

Post by stephenr »

unabst wrote: post #43
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

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.

Re: PHP 7 deployment at Dailymotion

#85

Post by seszett »

developer2 wrote: post #64
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

> ctype_digit is broken. Try passing integer values.

Well, ctype_digit takes strings, not integers. So don't be surprised if you pass the wrong type to a function and it doesn't work as you expected.

Some of your criticism is valid, but you can't go around talking about how PHP isn't rigorous enough, and then complain tha some functions don't work as you'd like when you give them a wrong argument type.

Your other arguments are more about bad developers as you say it yourself, anyone who actually cares about what he does knows you have to check equality with ===, while the array argument problem is less well known, but actually almost unrelated to PHP: POST or GET is user data that can be any type and should be checked. Only the last of your examples is actually a problem to me.

Re: PHP 7 deployment at Dailymotion

#86

Post by stephenr »

developer2 wrote: post #64
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

> The only correct ways to verify that a variable contains either a valid numeric string or integer is by comparing type, and then using a regex or a double string-then-int cast.

You know there is an entire extension dedicated to validating and sanitising inputs right?

All your type checking and regexes and double cast comparisons could be replaced with:

    if (($value = filter_var($value, FILTER_VALIDATE_INT)) !== false) { doStuff(); }
> You could try to blame PHP, but really it's the developers

At least we can agree on one thing.

Re: PHP 7 deployment at Dailymotion

#87

Post by babyrainbow »

developer2 wrote: post #64
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

>try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false.

That is hilarious! I love how even stuff that is supposed to fix other stuff itself end up being completely broken. But hey, it is documented.

Learning Php is like taking a massive loan. It get you started easily, but causes eternal suffering in the long run...

Re: PHP 7 deployment at Dailymotion

#88

Post by jwdunne »

developer2 wrote: post #64
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

In your example, 123e4 is a valid PHP number.

That said, input is a problem. In a dynamically typed language, it's easy for beginners to expect HTTP and requests in PHP work the same way. In reality, you will be coercing from string to wherever you are working with, which could also be an array of strings, or vice versa.

Input rules would be nice. For example, we always want id to always be an unsigned integer in this context and email will always be... and so on.

Dynamic typing makes, in this case, two types look like either plain old dynamic typing or leads to believing input has a homogeneous type.

In any case, I'm going to take a mag glass to some of our code today. Thanks!

Re: PHP 7 deployment at Dailymotion

#89

Post by babyrainbow »

Akujin wrote: post #38
nikcub wrote: 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…

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> The variables are there. You can use them or ignore them...

Ever worked in a team?

Re: PHP 7 deployment at Dailymotion

#90

Post by babyrainbow »

seszett wrote: post #85
developer2 wrote: post #64

Earlier quoted context omitted.

> Are you expecting it to be an integer? Easy > if(!ctype_digit($_POST['ID'])) { // throw exception here } ctype_digit is broken. Try passing integer values. ctype_digit(50) === true, but ctype_digit(100) === false. And "0000001" passes as true, which most people in the majority of scenarios would prefer not to pass. I can't remember what the even-worse-bug is with ctype_digit is, but even if you cast the value to st…

> ctype_digit is broken. Try passing integer values. Well, ctype_digit takes strings, not integers. So don't be surprised if you pass the wrong type to a function and it doesn't work as you expected. Some of your criticism is valid, but you can't go around talking about how PHP isn't rigorous enough, and then complain tha some functions don't work as you'd like when you give them a wrong argument type. Your other arg…

>Well, ctype_digit takes strings, not integers...

The problem is that the behavior is not consistant. Php is some parts c, some parts java and some part perl. That is the problem. It takes a encyclopedic knowledge of the documentation to know what part you are dealing with. And even that might not help you sometimes, because the documentation can be plain wrong at places...

>anyone who actually cares about what he does knows you have to check equality with ===

Can you write php code to store some string to string mapping in a php array and further down, check if a particular key exist in that array?

Post reply on HN