By Kevin Yank

News Wire: PHP Group accused of security incompetence

By Kevin Yank
  • “PHP developer Stefan Esser has said he will go ahead with plans to disclose dozens of security flaws in PHP in March, hitting back at criticism that the “Month of PHP bugs” project is nothing more than dangerous, self-serving publicity.”
    (tags: )
  • A brief refresher on why it’s a good idea to avoid having your content accessible via multiple URLs (note: redirects are fine), and how to implement URL rewriting on an IIS server so you don’t have to lose sleep over it.
    (tags: )
  • Yahoo! engineer Julien Lecomte blogs about his experience writing the new Browser History Manager in the Yahoo! UI Library (YUI), and the difference between this new solution and previous aproaches to the Back button in Ajax applications.
  • Following in the footsteps of Dojo, which offered up free hosting of its JavaScript library thanks to AOL late last year, Yahoo! is allowing developers to link to the YUI library files on its own servers for free.
  • Feed stats provider FeedBurner has released a fascinating report that compares the various feed readers’ traffic share. Particularly interesting are the numbers on audience engagement, which picks out subscribers that actually click on links.
    (tags: )
  • Flapjax is an interesting extension to the JavaScript language (which you compile down to plain JavaScript to deploy) that adds a number of useful facilities that allow you to write code that elegantly describes dynamic behaviors with very little code.

Got a link you’d like to recommend for the SitePoint News Wire? Great! Save the link on del.icio.us, and tag it for:sitepointlinks. Please include a description—it will increase the chances that we’ll select your link for the News Wire!


  • Ards

    Just hope Stefan Esser will make the right choice to help the PHP community instead of going against it for the “Month of PHP bugs”. I also think that it’s a self propaganda…

  • Rick

    The month of PHP bugs idea does sound alot like a publicity stunt.

    PHP does make it easy to write insecure code, but then again I used to write web apps in ASP and VBScript, I think the amount of time I spent compensating for security is about equivalent.

    All networked applications have the potential for massive security cockups (cough cough windows) especially if they are connected to the public internet, it just happens that PHP makes it very easy for developers who may never have heard of XSS and Code Injection develop applications.

    Things like magic_quotes_gpc prove that attempts to nanny users by taking responsibiltiy for security away from them always turn sour – they reduce flexibility and more importantly can’t hope to gaurentee security in all situations.

    I don’t think its fair to blame PHP for allowing developers to write insecure applications, just as I wouldn’t argue that you can blame C++ for allowing developers to write applications with memory leaks!

  • @Rick

    Month of PHP bugs will be about bugs into PHP itself, not users’ applications.

  • jamiemcd

    I use YUI. It’s a great javascript library. However I noticed an important comment on the Free Hosting of YUI Files from Yahoo! discussion. If your site is secure, such as https://www.example.com, you need to continue hosting your own YUI files, since Yahoo! does not offer secure hosting. I ran into this same problem with including the javascript files needed for Google Analtyics. I would get a security warning on any pages using SSL. Fortunately, Google did offer secure hosting of those javascript files, as described here.

  • What is the benefit to having your Javascript hosted remotely? I can only think of downsides.

  • What is the benefit to having your Javascript hosted remotely? I can only think of downsides.

    The benefit is that your site uses less bandwidth on your server, and most browsers will be able to load your site more quickly (most browsers will only download 2-4 files from a particular server at once).

    What downsides can you think of?

  • The downside to me was that your site (files you manage) are split up, with some out of your direct control. If you wanted to regroup certain scripts into a single file (depending on your usage patterns) you wouldn’t be able to do it.

    If you wanted to (for example) make some scripts .php files served as JS to compress you wouldn’t be able to do it.

    You may want to make trivial changes (e.g setting up shortcuts to the long YUI names) to the library files.

    You have another point of failure. Your site may be online, but the JS that powers it offline (unlikely though).

    If your site hard-links to specific JS files (admittedly not a good idea) and you want to utilize new versions you’d have a lot of links to change.

    These are not insurmountable issues. Mostly I like the psychology of having the site in one place. For concurrent connections you can always setup a subdomain on your own server and load the JS files via it. Still have to supply your own bandwidth though :)

Get the latest in Entrepreneur, once a week, for free.