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

PHP: The Right Way

phptherightway.com

Post reply on HN
Print view View original

51–60 of 233 posts

Re: PHP: The Right Way

#51

Post by unconed »

xd wrote: post #24
kingkilr wrote: post #18

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

SQL injection attacks alone are almost always a result of not filtering input...

This the wrong way to look at it, and yes, the PHP world always does this wrong because they're too focused on HTML.

SQL injection occurs when you're not escaping data while producing output, namely, an SQL query sent to the DB.

XSS attacks occur when you're not escaping data while producing HTML, but you don't need angle brackets to do it. allows for XSS injection with just a quote character.

Header injection attacks occur when you're not escaping data while producing HTTP/MIME headers, and all you need is a line-break character.

The escaping always depends on the output context, and the data in the database cannot be made safe for all these contexts. You will still need to allow people named "O'Brian", let people post "<_<" smileys, use Unicode in their names, etc.

Re: PHP: The Right Way

#52

Post by Kudos »

timaelliott wrote: post #49
aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

That's really just a question of trust. If you know what Composer is, you trust it. 'apt-get install whatever' is just as magically scary and dangerous.

No it isn't, there's GPG signing and things going on there.

Re: PHP: The Right Way

#54

Post by jimmytucson »

I didn't understand this:

    4.2. Properties

    This guide intentionally avoids any recommendation regarding the use of 
    $StudlyCaps, $camelCase, or $under_score property names.

    Whatever naming convention is used SHOULD be applied consistently within a 
    reasonable scope. That scope may be vendor-level, package-level, class-level, 
    or method-level.

    4.3. Methods

    Method names MUST be declared in camelCase().

Re: PHP: The Right Way

#55

Post by ecaron »

1amzave wrote: post #48
aw3c2 wrote: post #40

curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.

Indeed, especially coming after this further up the page: > Never ever ( ever ) trust foreign input introduced to your PHP code. Where'd I put that sense of irony...

Except that there's a significant difference between "trust" of input from the user vs. "trust" of the software stack you use as a foundation.

Unless you've read every line of the Linux kernel, we all succumb to the later point sooner or later.

Re: PHP: The Right Way

#56

Post by unconed »

birdcircle wrote: post #50
kingkilr wrote: post #18

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

Input is almost always filtered. Without mincing the semantics of that, let's say you receive free-form NL query as input. You don't filter that to reduce it to core terms you send to the database? You don't remove prepositions? You don't tokenize at all? Input is ambiguous and reduced/filtered into pseudo-meaningful terms to return relevant output.

This is true for all structured data, but the problem always comes from freeform text fields, which you cannot filter for one context without mangling or destroying the data for all other purposes—except perhaps trivial things like trimming leading/trailing whitespace.

Re: PHP: The Right Way

#57

Post by Udo »

Kudos wrote: post #52
timaelliott wrote: post #49

Earlier quoted context omitted.

That's really just a question of trust. If you know what Composer is, you trust it. 'apt-get install whatever' is just as magically scary and dangerous.

No it isn't, there's GPG signing and things going on there.

  No it isn't, there's GPG signing and things going on there.
That's really just Cargo Cult security, isn't it? Signed packages can just as easily be malicious. In fact a repository server could be a much worthier target for the injection of bad code than a single, relatively obscure web project.

Re: PHP: The Right Way

#59

Post by LnxPrgr3 »

xd wrote: post #17
BadCRC wrote: post #14

These guidelines won't save you from some bullshit PHP "rules", such as: http://stackoverflow.com/questions/5810168/php-foreach-by-re...

How is that a "bullshit PHP rule"? If you for loop in C, setting a pointer each iteration, you would expect the pointer to still be set the the last assignment in the loop once you're out of it.

C lets you define variables with block scope:

  int main(int argc, char *argv[]) {
  	for(int i=0;i
The last line fails to compile—'i' is no longer defined after exiting the loop.

Java:

  public static void main(String[] args) {
  	for(int i=0;i
That also won't compile.

Coming from a language that supports variables with block scope, PHP's behavior is very surprising indeed. If the first mention of $object is in the loop, I can understand someone expecting $object in the second loop to be a distinct variable that just happens to share the same name.

This behavior is even surprising coming from Perl, though for a slightly different reason:

  @array = ('c', 'c++', 'java', 'perl');
  foreach $item (@array) {
      if($item eq 'perl') {
          $item = 'php';
      }
  }
  foreach $item (@array) {
      print $item . "\n";
  }
For that matter, PHP's reference semantics are a little surprising in general coming from any other language I've ever used.

Re: PHP: The Right Way

#60

Post by mgkimsal »

kellishaver wrote: post #21
codeguy wrote: post #11

Earlier quoted context omitted.

I think it's less about being "superior" than standardizing on a common style. Makes it easier to get up and running with someone else's code. But if your team agrees on a common but different style, that's fine too. It accomplishes the same goal. I'm only suggesting the official standard for new PHP developers.

Right. I think the main take-away from it is to be consistent and make sure everyone on your team is on the same page about the coding style. I see the PSR as a basic set of good recommendations, rather than something that must be followed. It's a good idea to follow it, but at least follow something . My only complaint with it personally is that I Can. Not. Stand. putting opening brackets on their own line.

I understand it's not an either/or situation but...

I'd MUCH prefer people spend time writing tests for their code vs debating/arguing/refactoring code style. If your tests and good and coverage is high, there's far less chance I should ever even have to muck around inside your libraries, much less modify them.

And again, one doesn't preclude the other, but I see so many people making a bit stink over style - tabs vs spaces et al years before the PSR stuff - yet rarely do I see even 20% of that effort spent on getting people to test.

I say this not as someone who tests everything 100%, but as someone who doesn't do much of it, and understands the importance of it. When I'm deciding to use someone else's libraries, I never make a decision based on the code style they've chosen - I base it on maturity, documentation, and tests/examples provided (when there's a choice, sometimes you don't have a choice, or you roll your own). The really good libraries? I never even have to look a their code - it might be all run together on one line for all I care - it just works.

Post reply on HN