I had the pleasure of discussing with fellow members of the PHP community a very sensitive topic: sexism in tech. I have been invited to a special episode of Voices of the ElePHPant with Elizabeth (Beth) Tucker Long, Elizabeth (Liz) Naramore and Laura Thomson. Cal Evans was the host. The podcast's page features links for some of the topics discussed. The purpose of this post is not to transcribe the podcast, but to share with you what I learned from this conversation and what I personally took away from it.

She talks about some of the comments that came up about the general tech culture and attitudes around women, some thoughts about "brand hygiene" and her opinions on wether the tech industry (or more specifically software development) will mature past this gender issue being a problem.

Solr supports multiple output formats. Some are for general use (xml, json) and some are even language specific. If you're using PHP these are the most logical response writer formats: xml, json, phps (serialized php), php (php code to execute). On top of that PHP offers multiple ways to parse XML. I'm benchmarking these options to determine the most efficient decoding to implement in the next major version of Solarium, but the results should be useful for any PHP Solr implementation.

He includes a snippet of code he's using to generate the benchmarks, a PHPUnit test that pulls in two different json-based results and, for now, just runs a json_decode on it. You can see the results of his testing here, graphing out the different response handling methods and their time (in milliseconds) to parse the response. It's interesting to see that there's a direct relation to the size of the data set and how long it takes for the methods to execute.

The current code for his benchmarks is available over on github

This post is going to describe how I've ending up designing, what I consider to be a fairly RESTful web API. I'm far from being an expert, and this is definitely the closest thing to a RESTful API that I've ever created, so I'm not even experienced with REST APIs. [...] Until about 6 months ago, I'd always been sceptical of creating RESTful APIs, but I think I've had a few pennies drop since then that have made me fairly confident that I grasp the basics pretty well.

He touches on topics like: authentication, the Richardson Maturity model, HTTP verbs, sample request and response messages and some BDD-style tests to predict the output of a basic request.

As of the time of this post there's about sixty-five comments posted to the thread with widely ranging opinions:

• "How is [lots of separate libraries scattered around] better than simply using a framework?"
• "This is part of the reason for the PSR0 reference for auto loaders [...] Part of the problem is an inconsistent way to load modules."
• "I would love to see this become a trend in the PHP community. I think this is exactly the direction needed to make PHP exciting again and regain mindshare in the wider dev community."
• "I know, many people are currently on that micro trip but seriously, I think that there is as much to microframeworks as there is to microoptimization"
• "A framework is a tool. If you don't need it, why use it?"
• "There's a tool for ever job, I agree some projects or companies "need" something like Zend or Symfony for their enterprise projects. Whether or not you'd want to work on a project with 1000's of classes is something else all together."

Read the full responses to Ed's article here.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

If you've ever built a Zend Framework MVC app which makes AJAX calls, you may have noticed that if an error occurs, you'll get a chunk of JSON followed by the HTML for the error page. If you've built a layout, you'll get all of that back to. This is fine if your users hit the page in the browser but it can cause problems with your JavaScript being able to correctly decode your JSON.

The fix is pretty simple, though, and only requires that you add the error handling action to the Ajax context to force it to drop the layout and any other HTML that might come along with the view. He includes a bit more code to have the error handler include the exceptions and pass them out to be included in the JSON response.

I decided to click the link [in my feed reader] and give the article a read. Not overly shocking was the fact that I didn't find the content of the article to be, how shall I say this..., overly factual. It's not really a "tutorial", but more of a "here's some code that's secure". A quick review of the code found more than one vulnerability, and some significant things that I would change about it (as well as a few "really bad practices").

He walks through each of the files included in the original tutorial - Authenticate.php, Register.php and Logout.php - and talks about things like brute force detection, password verification, registration handling and session serialization. He finishes it off with a list of twelve overall issues he noticed during his work along with solutions for each (usually very simple ones too).

Today an article popped into my feed reader that raise my eyebrows. The article's title is "Building Secured Web Applications Using PHP - The Basics". The summary of the item looked interesting, so I decided to open it up...What I found blew me away. It was filled with loads of bad information including some down-right wrong suggestions. Let me go through point by point and shed some light on the subject...

His response goes back through the original article by section header and explains either why the advice was bad and/or the more correct way to do things.

Security is not something you can learn in a page. It's not something that you can learn in a single book. It takes a lot of time and effort. It should not be trivialized into a simple "Do this and you'll be secure" style post. It sends the wrong message...

I've hacked together a small example on how to easily cache full responses in Lithium. If you need to cache full Response objects in Lithium (which means that your controllers don't even get called when there's a cache hit), you can place this in your app/config/bootstrap/cache.php file (note that this is certainly not "production ready", but it should give you a starting point).

The code adds a new filter to run on execute that takes the current object (the Response object hit the first time) and use the Cache functionality to push it into storage. Their cache key is based on the URL, so each requests is cached individually. You can find out more about filters and the framework at Lithify.me.