curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.
haha. Always good advice. But I checked. It's fine :)
PHP: The Right Way
41–50 of 233 posts
Re: PHP: The Right Way
#42curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.
RVM's installation is similar:
A far cry from the safer/verified "download this and check it's MD5 checksum" method that I'd prefer.
Seriously, fixing package management so we can continuously integrate arbitrary code would be great. Getting arbitrary OS package creation to be almost as easy as pushing code to GitHub seems like a very worthy goal.
Re: PHP: The Right Way
#43curl -s http://getcomposer.org/installer | php is creepy. Never ever run other people's code without at least giving it a glance.
Reminds me of how you get mysqltuner:
wget mysqltuner.pl
perl mysqltuner.pl
(Yes, they actually have a .pl domain for it)
Re: PHP: The Right Way
#44While PSR-1 has pretty good universal guidelines, PSR-2 goes too far in insisting on subjective preferences (spaces over tabs, 80-char lines, bracketing styles). We should not pretend that there is a "correct" answer to these choices, just as long as they stay consistent on a per-project basis.
All told, I love site, and I hope it keeps iterating. PHP may be ugly, but it's powerful, and most of its bad reputation comes from good coders having to pick up the pieces from bad coders.
Re: PHP: The Right Way
#45One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.
Agreed, most input should not be filtered. There are some exceptions though like stripping whitespace and dashes from credit card numbers and phone numbers.
The filtering of input has nothing to do with security (that should be handled by output escaping and paramterized queries) and should only be used for improving the quality of the saved data.
Re: PHP: The Right Way
#46Earlier quoted context omitted.
SQL injection attacks alone are almost always a result of not filtering input...
With parametrized queries, that becomes a non-issue, but I still see no point in cluttering the database with data that's just going to be filtered out at some point - might as well filter it before it goes into the DB to begin with. The exception, of course, being those rare cases when some users need to see the filtered data and others need to see the raw data, but even then, you likely won't want to allow everythi…
Parametized queries are just another way of filtering input ..
Re: PHP: The Right Way
#47One 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...
In my anecdotal experience SQL injection attacks are almost as often caused by relying on filtering data and then forgetting to filter it for some fields. You should instead rely on parametrized queries and only use string operations to build queries where you must (and then do it very carefully).
SQL injections are very rare to non-existent in code where the programmers generally rely on parametrized queries.
Re: PHP: The Right Way
#48curl -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...
Re: PHP: The Right Way
#49curl -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.
Re: PHP: The Right Way
#50One 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.