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

PHP Commandments

biasedphp.com

Post reply on HN
Print view View original

91–100 of 117 posts

Re: PHP Commandments

#91

Post by rmrfrmrf »

grobolom wrote: post #26
bru wrote: post #14

Earlier quoted context omitted.

>Where would something like this fit, if not a general helpers.php type file? In debugging.php alongside with other debugging helpers?

Maybe if it's used solely for debugging, but there are cases where simple functions aren't easy to place. Consider implementing the array_column function for pre-5.4 PHP. Or things like method pull, index grouping, or array_select_keys functions. What helper library should a function like the following exist in? function array_select_keys(array $dict, array $keys) { $result = array(); foreach ($keys as $key) { if (ar…

Uhh, really?

   array_intersect_key
http://php.net/manual/en/function.array-intersect-key.php

Re: PHP Commandments

#92

Post by eru »

Shorel wrote: post #76
eru wrote: post #71

Earlier quoted context omitted.

tabbyjabby didn't say it's bad. They just said it's not OO.

I know. It implies the assumption that not complying with OO is something code should avoid as a rule of thumb. I'm the one saying that strict OO is bad because it's verbose and its slower than the alternative.

Count me in as saying that not only strict OO is bad, but OO is a bad idea in general. At least in its usual form. You might manage to tackle something OO-like on, say, FP, and get away with it.

Re: PHP Commandments

#93

Post by rmrfrmrf »

kijin wrote: post #82
grobolom wrote: post #26

Earlier quoted context omitted.

Maybe if it's used solely for debugging, but there are cases where simple functions aren't easy to place. Consider implementing the array_column function for pre-5.4 PHP. Or things like method pull, index grouping, or array_select_keys functions. What helper library should a function like the following exist in? function array_select_keys(array $dict, array $keys) { $result = array(); foreach ($keys as $key) { if (ar…

I have a similar dilemma with some of my helper functions. For example, I have starts_with(), ends_with(), and contains() for super easy string comparisons, is_between() for numerical comparisons, and custom implementations for a few built-in functions such as hex2bin() that don't exist in older versions. These are so general in scope that it would be awkward to place them in their own \Namespace\Class.

I'd probably break them all down into classes based on function (EasyString, EasyNumber, BuiltIn).

    namespace App\Library;
    class EasyString {
        public static function starts_with();
        ...
    }
and then just use them like this:

    use App\Library\EasyString as ES;
along with an autoloader.

Re: PHP Commandments

#94

Post by grobolom »

rmrfrmrf wrote: post #91
grobolom wrote: post #26

Earlier quoted context omitted.

Maybe if it's used solely for debugging, but there are cases where simple functions aren't easy to place. Consider implementing the array_column function for pre-5.4 PHP. Or things like method pull, index grouping, or array_select_keys functions. What helper library should a function like the following exist in? function array_select_keys(array $dict, array $keys) { $result = array(); foreach ($keys as $key) { if (ar…

Uhh, really? array_intersect_key http://php.net/manual/en/function.array-intersect-key.php

array_intersect_key does not do the same as array_select_keys. You can emulate it using array_intersect_key, but either in a more confusing or slow way.

  $array = ['a' => 1, 'b' => 2, 'c' => 3, 'd' => 4];

  array_select_keys($array, ['a', 'b']);
  array_intersect_key($array, ['a' => '', 'b' => '']); // OR
  array_intersect_key($array, array_flip(['a', 'b'])); // OR
Neither are elegant.

In either case, that wasn't the point. This is a basic kind of functionality that doesn't belong to any particular class in most code bases. So in this case, having a class of 'helper' functions like these isn't bad.

Re: PHP Commandments

#95

Post by rmrfrmrf »

UnoriginalGuy wrote: post #90
chacham15 wrote: post #64

Earlier quoted context omitted.

No. >MD5 was very much acceptable for the longest time. MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. This is bad for passwords. What you should be using is the opposite: an expensive hash to compute. This is bcrypt which has been in use since 1999 (and what the PHPass is based on). This is a clear example of "Dont do your own crypto" becau…

> MD5 was never a good password hash. Neither is SHA1,256,etc. The reason is that they are crypto hashes optimized for speed. That's strange to hear you say that, because I remember people having huge arguments in the 1990s about how they couldn't use MD5 because it was /so/ slow and how 3DES was the only way to go! I swear people love to re-write history. > This is a clear example of "Dont do your own crypto" becaus…

> "OMG USE bcrypt IT IS THE BESTEST AND WILL BE SECURE FOREVER!"

5000 people in a room all shouting this repeatedly -- pretty much how I envision every Rails dev conference.

Re: PHP Commandments

#96

Post by rmrfrmrf »

grobolom wrote: post #94
rmrfrmrf wrote: post #91

Earlier quoted context omitted.

Uhh, really? array_intersect_key http://php.net/manual/en/function.array-intersect-key.php

array_intersect_key does not do the same as array_select_keys. You can emulate it using array_intersect_key, but either in a more confusing or slow way. $array = ['a' => 1, 'b' => 2, 'c' => 3, 'd' => 4]; array_select_keys($array, ['a', 'b']); array_intersect_key($array, ['a' => '', 'b' => '']); // OR array_intersect_key($array, array_flip(['a', 'b'])); // OR Neither are elegant. In either case, that wasn't the point.…

array_intersect_key([], array_flip([])); is pretty idiomatic actually lol, but that's PHP for you.

The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions. array_select_keys would go perfectly into a helper class called ArrayHelper with a bunch of other array convenience functions.

I'm pretty sure the author was talking about a helpers.php file like this:

    myGetPlaintextUserPasswordFromGET();
    encryptPasswordMD5(); //don't use this one anymore
    connect_to_my_mysql_database(); //complete with hardcoded values
    increment_for_loop();
    my_input_sanitizer();
    encryptPasswordSHA1(); //don't use thiS!!!
    my_improved_input_sanitizer(); //use this one from now on!!
    add_user_to_database();
    getCharacterAtPosition();
    generate_a_random_number_between_one_and_ten();
    show_user_alert();
    encryptPasswordSHA1_withsalt(); //USE THIS OnE!
    myConvertEmoticonToSmiley();
    ...
nightmarish.

Re: PHP Commandments

#97

Post by acabal »

For anyone interested in taking the next step for some of these suggestions (i.e., "OK, never put variables in SQL, what do I do instead then?"): I maintain https://phpbestpractices.org, which is an attempt to document the "best" solutions to common low-level tasks, like DB access, which have lots of possible dangerous approaches.

(Note I only talk about the version of PHP that ships with Ubuntu 12.04 LTS, so brand-spanking-new stuff like password_hash() isn't in there.)

Re: PHP Commandments

#98

Post by grobolom »

rmrfrmrf wrote: post #96
grobolom wrote: post #94

Earlier quoted context omitted.

array_intersect_key does not do the same as array_select_keys. You can emulate it using array_intersect_key, but either in a more confusing or slow way. $array = ['a' => 1, 'b' => 2, 'c' => 3, 'd' => 4]; array_select_keys($array, ['a', 'b']); array_intersect_key($array, ['a' => '', 'b' => '']); // OR array_intersect_key($array, array_flip(['a', 'b'])); // OR Neither are elegant. In either case, that wasn't the point.…

array_intersect_key([], array_flip([])); is pretty idiomatic actually lol, but that's PHP for you. The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions. array_select_keys would go perfectly into a helper class called ArrayHelper with a bunch of other array convenience functions. I'm pretty sure the author was talking about a helpers.php file like…

The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions.

It doesn't stand. There's absolutely nothing wrong with having a file with simple helper functions.

  ArrayHelpers::array_select_keys();
is in no way better than

  array_select_keys();
There is plenty wrong with the helpers file you described at the end of your post. But it's because those functions break basic programming principles, not the fact that they happen to be simple functions in a file (and most of them are not even simple).

Re: PHP Commandments

#99

Post by thaumaturgy »

UnoriginalGuy wrote: post #45

> NEVER hash passwords with MD5/SHA-1/Hash-of-the-day > PHPass will make life easy for yourself and keep your users' passwords secure. MD5/3DES/SHA-1 are relatively broken. But saying "use this magical library" is really far from a solution. Who's to say that that library won't be broken tomorrow and then someone else won't write an article next week saying "don't use PHPass!" Programmers just need to stay up-to-date…

You're right that today's algorithms or libraries might be broken at some distant point in the future, but I don't see how that would change today's recommendations. Today's best practices are the same regardless of what will happen in ten years. When something better comes along, then people should move to that; until then, PHPass and bcrypt are reasonable suggestions.

> But saying "use this magical library" is really far from a solution.

PHPass is managed by OpenWall. They're some pretty smart people. The only niggle I can think of with PHPass is that they read from /dev/urandom without trying /dev/random; theoretically /dev/urandom is unsuitable for cryptographic applications, but using /dev/random is tricky and error-prone, especially in VPS environments. (You can install haveged on Debian to feed /dev/random if you're interested in that sort of thing.)

Given the choice between using OpenWall's PHPass bcrypt implementation or rolling my own, I'd use theirs without a doubt.

What alternative would you suggest?

> MD5 was very much acceptable for the longest time. Back when everyone was using 3DES, MD5 was seen as the Bcrypt of the time. So saying that it "never was acceptable" is simply nonsense.

True, but sort of pointless. My best recollection is that MD5 was last considered OK back in 1997 or thereabouts, but I might have early-onset alzheimer's or something.

Re: PHP Commandments

#100

Post by thaumaturgy »

adamors wrote: post #12

Are people still using PHP without frameworks these days?

I don't use frameworks with PHP. I build as I go, but it's always purpose-built.

I confess that I don't get the point of PHP frameworks: PHP is a framework; I've never needed to do more than tweak it a little to fit my personal style. For example, I have a "DBI" class file that's all of 133 lines (including tags & comments) that's a light wrapper around PDO, with some error logging & management and an easy iterator over result sets. It does everything I need for databases; I genuinely can't imagine needing anything more complex.

My html library is a little bigger -- 1200ish lines currently -- but that's largely because I implemented bits of jQuery into PHP ...

Post reply on HN