<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Fri, 09 Jan 2009 22:13:15 -0600</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[PHP Discovery Blog: Dangers of Remote Execution]]></title>
      <guid>http://www.phpdeveloper.org/news/9092</guid>
      <link>http://www.phpdeveloper.org/news/9092</link>
      <description><![CDATA[<p>
On the PHP Discovery blog, there's a <a href="http://phpdiscovery.com/dangers-of-remote-execution/">new post</a> reminding PHP developers of some of the more dangerous ways that remote execution could effect your site and some of the common entry points it can have.
</p>
<blockquote>
PHP has numerous ways to execute raw PHP code unless you the programmer stops it.  Best way in preventing these methods is making sure you check the input of what your users are inputting, and making sure you escape all malicious actions that a hacker,cracker, kiddy scripter might want to do to your website. 
</blockquote>
<p>
He summarizes four of the things from the <a href="http://apress.com/book/view/1590595084">Pro PHP Security</a> book from Apress (by <i>Chris Snyder</i> and <i>Michael Southwell</i>) that can leave holes in you application for would-be explots - preg_replace, shell_exec/exec, eval (which we all know is only one letter from "evil" anyway) and require/include.
</p>]]></description>
      <pubDate>Wed, 21 Nov 2007 13:48:00 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Ivo Jansch's Blog: The danger of Fluent interfaces]]></title>
      <guid>http://www.phpdeveloper.org/news/4583</guid>
      <link>http://www.phpdeveloper.org/news/4583</link>
      <description><![CDATA[On <i>Ivo Jansch</i>'s blog today, he takes the other side of things on the issue of <a href="http://www.achievo.org/blog/archives/25-The-danger-of-Fluent-interfaces.html">fluent interfaces.
<p>
<quote>
<i>
After Martin, Mike and Paul have demonstrated the usefulness of Fluent Interfaces, I'd like to take a look at the downside.
<p>
Ironically, Martin's original example already demonstrates the problem. (In the example) newOrder could be implemented in two ways: Create an order and return that new order, and Add an order to this customer and return the customer.
<p>
This can lead to confusion; the 'with()' method employs method b. If you think that newOrder returns an Order, and hence 'with()' is a method of the Order class, look at 'skippable'. Martin states that order lines are skippable. So what's in front of skippable() is an OrderItem. That means that with() must have returned an OrderItem. If that is true, then with() is a method of OrderLine too!
</i>
</quote>
<p>
Confused yet? Well, be sure to <a href="http://www.achievo.org/blog/archives/25-The-danger-of-Fluent-interfaces.html">check out his examples</a> - they help to clear up at least the items mentioned above. His point is that, while the fluent interface does make it more readable, it can also make it more confusing - taking things down to such a simple level can sometimes eliminate some needed complexity to make things work properly (or as the user percieves "properly" to be)...]]></description>
      <pubDate>Fri, 30 Dec 2005 07:07:45 -0600</pubDate>
    </item>
  </channel>
</rss>
