Planet-PHP

If you are a "connected" developer, you are probably aware of the major vulnerabilities found in Ruby on Rails recently. To be fair, we've also found some serious issues in the Symfony code during the last few months.

As security management should be a top most priority for us and our customers, I've recently worked on improving the current situation in the Symfony world, with an enhanced security process. But security management is also a very important topic for me because Symfony is quickly growing in popularity for both end-user projects and Open-Source ones; and more exposure also means more interest from the "bad guys".

One of the goal of good security issues management is transparency. That's why the Symfony project has a simple way of reporting security issues (via the security [at] symfony.com email address), an easily accessible list of security advisories, and a well defined blog post template to announce security issues. Recently, we have also enforced the need to have a CVE identifier for all security issues to help the broader community to be aware of Symfony security issues.

The best advice one can give you is to upgrade your favorite libraries as soon as possible when new versions with security fixes are released. Easier say than done.

How do you know that a new release is out? How do you know that it contains security fixes? For Symfony, you can subscribe to the RSS feed of the Symfony blog, or you can have a look at our security advisories from time to time. But sometimes, that's not possible as the project does not even have a blog. Was the security fix announced on Twitter? Quite possible. But most of the time, smaller libraries just release a new version without any proper security announcement.

But I want to provide a simple and efficient way to check for vulnerabilities in a project and I want to serve more than just the Symfony community. That's why I'm really proud to announce a new SensioLabs initiative: a simple way to check if your project depends on third-party libraries with known security issues. The website explains how it works in details (https://security.sensiolabs.org/), but basically, this initiative gives you several ways to check for security issues in your project dependencies based on the information contained in you composer.lock file (you are using Composer to manage your dependencies, right?):

• The website itself allows you to upload a composer.lock to check for vulnerabilities;

• A web service can used with curl or to integrate that tool into your own continuous integration process (it returns its results as plain text or as a JSON array);

• A command line tool gives you the same feature as the web service and the website but nicely packaged as a simple Symfony command.

Of course, the most important part of this initiative is the database where known security vulnerabilities are referenced. The database is hosted on Github: https://github.com/sensiolabs/security-advisories. We have already referenced known vulnerabilities for Symfony, Zend Framework, and some well-known Symfony bundles, but the idea is for the community to help us add more libraries and more importantly to update the database whenever a security issue is fixed in a library. Even if you don't have a way to easily announce your security fix to the world, at least, reference it in the database; contributing to the database is really easy: fork the repository, contribute your changes, and send a pull request (you can even do everything from the Github web interface if you want).

Check your projects, upgrade your dependencies when needed, and contribute to the database!

I'm delighted to announce that my new book "PHP Web Services" is now available as an early release! This is a project that I've been working hard on for the last few months, trying to put my extensive and hard-won experience of working with APIs into words and examples to make it easy for others to get up to speed in this area.

The book isn't huge (or expensive, hint!), but it aims to give solid theory in a practical and approachable way. There's the topics you'd expect to see, covering HTTP and verbs and headers and status codes, and also around data formats. It also covers RPC services including SOAP, and also has a chapter (predictably the longest one!) about REST. I've tried to go beyond simply the "how to do" and into the "how to do in a kick-ass manner" realm, so there are chapters about how to design your API and choose what kind to build, how to handle errors, how to make your API really robust - and of course how to debug when things go wrong!

The early release means that you get the digital copy now, and updates will arrive in the next few weeks as we finalise on the editing. The book is written and the technical review is done, so it's pretty much production ready, but we're still working on editing the language - and probably ironing out my British spellings! If you'd like to read it, please do. Any and all feedback is encouraged and warmly welcome ... and if you want to write a review then I owe you a beer and eternal gratitude!

Whether you get in touch or not, if you read this book then most of all I hope it helps you meet your goals, that was always my aim :)

Lorna is an independent web development consultant, author and trainer, available for work (interesting projects only). This post was originally published at LornaJane

I’m happy to say that many developers have found their way to Jasny Bootstrap. Especially the file upload component, is very popular. It can replace any normal <input type="file"> element to display a nice widget that is consistent across browsers and can show a preview for images.

This is just an image

The documentation shows the html to use, but it doesn’t show how to use it with existing files. I’ll explain it here.

The html stays largely the same. Change fileupload-new to fileupload-exists for the .fileupload container div (line 1). Put the <img> for the existing image in the .fileupload-preview div (line 4). If you’re not image preview, put the file name in the .fileupload-preview div instead.

1
2
3
4
5
6
7
8
9
10

<div class="fileupload fileupload-exists" data-provides="fileupload">
  <div class="fileupload-new thumbnail" style="width: 200px; height: 150px;"><img src="http://www.placehold.it/200x150/EFEFEF/AAAAAA&text=no+image" /></div>
  <div class="fileupload-preview fileupload-exists thumbnail" style="max-width: 200px; max-height: 150px; line-height: 20px;">
    <img src="/images/example.png">
  </div>
  <div>
    <span class="btn btn-file"><span class="fileupload-new">Select image</span><span class="fileupload-exists">Change</span><input type="file" name="myimage" /></span>
    <a href="#" class="btn fileupload-exists" data-dismiss="fileupload">Remove</a>
  </div>
</div>

Truncated by Planet PHP, read more at the original (another 17174 bytes)

Note: This article was originally published on the october/2011 issue of php-architect. If you like it keep a close eye on the Community Column in the magazine, where I get the chance to write alongside other awesome community people.

Vacuums are a very interesting part of physics. From the latin vacuum means “empty”, basically describing an empty space, which is very similar to what happens to an area where there is not a User Group present. Its empty, its PHP developers are looking for support and sharing their ideas in some other place, probably even neighboring user groups. This does not mean the talented people are not there, it really means that they are not taking full advantage of their potential and getting to know each other.

Some developers may notice this absence of “particles” and interaction between them in their local area, this may even cause them enough of an itch that it needs to be scratched, and thus a User Group starts forming. But how hard is it to start a group? Can anyone do it? what really am I going to have to do to get all these particles into my vacuum and end this “empty space” in my region?

Well that’s where a different characteristic of vacuums come in, suction. You probably remember this from school, vacuum containers are always trying to implode, the explanation is quite simple, a vacuum causes a lower pressure inside its container, and matter has a tendency to move into lower pressure areas trying to equalize the environment, this causes suction.

What does that mean for User Groups? Well the same applies, this vacuum of community activity causes a lower pressure environment and eventually it will start sucking in new contributors, new developer and generate more and more activity. As Kevin Costner said in that long ago movie “Build it and they will come”, that is very true for starting new communities, you just need to give the first few steps and very soon, you will not be walking alone anymore.

The firsts steps are always simple, your first objective should be to find developers in you area, give them a place to discuss, to get together. Its easier if you start this virtually, create a forum or a discussion list. Somewhere they can trade their ideas and get opinions. Of course just creating this is not enough, you need to make people aware of this list, its much like applying heat to particles. Back to school, do you remember what heat was to matter and how it spread? Let me remind you, its all about movement. Heat causes one molecule to start moving more then usual, which makes it bump into another which then bumps into another and pretty soon everyone is bouncing around like bumper cars in a circus.

The same principle will spread your virtual meeting place. Talk to one developer, your co-worker for example, tell him to tell his friends who are also developers. This will start the chain reaction, but don’t stop there, look for companies that have PHP developers, find them in job boards, talk to recruiters, just get the word out. As much as recruiters can be a pain, good recruiters will love to have a place to find out the names of new PHP developers, so they will actively broadcast your meeting place. After you have a lively group in your virtual meeting place, take it to real life, suggest a meeting at a pub, or if you got someone interested in speaking, host a talk at a local company.

One thing will lead to another, all the entropy and vacuum talk we did before will start applying, activity will start bringing in new contributors and before you know it, you have and active User Group in your hands. Even better, you are not alone, leaders from around the world are out there ready to give you ideas and help you kickoff new activities in your group. Come join the talk at https://wiki.php.net/usergroups.

Also, this is not a one man job, count on your members at least one of them will have the “built of a leader”, bring him on board. As I said in my first column, we are not Leaders, we are just cat herders and temporary, we will come and go, but the group needs to stay. So share responsibility, look for partners and sponsors, recruiters can be very good partners, if they respect the limits imposed by you. Local companies will probably also be looking for talent, so taking the event to their headquarters is even better then handing them a resume or giving them a job board to advertise spots, all they need to do is open their door and pay attention, surely they will be glad to help.

These are all lessons I learnt from the past, I have actively participated in the creation of two User Groups and this is how it started. Every group will find its own sweet spot on how meetings are held and how its managed, I remember participating at the community panel at php|tek one year w

Truncated by Planet PHP, read more at the original (another 2251 bytes)

HTTP/1.1 500 Internal Error
Content-Type: application/api-problem+json

{
    "describedBy": "http://www.w3.org/Proto

Truncated by Planet PHP, read more at the original (another 4904 bytes)

The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features.

Here are some personal observations and suggestions that show how I have seen feature acceptance and the RFC process work in practice. These notes augment the steps in How To Create an RFC. I hope they help set expectations about the PHP RFC process and feature acceptance in the PHP language.

• Before starting an RFC, review existing RFCs and search the mail list archives for similar ideas and use this information to explain what your RFC will bring to the language.

• If you're new to PHP core development, mail the "internals" mail list to judge interest before you start your RFC. If you get no reaction (this is likely) or positive reaction then create the RFC. Core PHP developers with karma will know when they can skip this step.

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.

• Don't start an RFC (or mail list discussion) about standardizing PHP function names and function argument orders. There are several historical reasons why the functions are what they are (including compatibility with underlying libraries), and many good reasons why the change would be counter-productive causing more end-user confusion, would lead to unmaintainable PHP engine code, and generally be a waste of everyone's time when they could be doing more interesting projects. This has been discussed ad infinitum. Review previous discussions and feel free to fork PHP on github.

• Your RFC should talk about all PHP areas that will be affected: php.ini, different SAPIs, engine, extensions, etc. List similar features. List similar features in other languages. Link to references. Give an estimate of the actual positive impact to user code.

• Your RFC will be used to create the PHP documentation, so make its sections re-usable. Explain concepts and details. Keep the RFC technical and have plenty of examples.

• Many current PHP RFCs don't contain enough detail, nor do they capture the pros & cons that were discussed on the mail list. You can, and should, do better than these RFCs.

• An implementation is not mandatory while proposing an RFC but it can help persuade people and help fine-tune the design. Note that if you are unable to implement the RFC, and no one else volunteers during the discussion period, then your RFC is unlikely ever to be implemented.

• Don't start an implementation too early. Get support for the feature concept from the "internals" mail list before spending time on coding - unless you want a learning experience.

• If you do have an implementation, make it clear whether the implementation is a simple prototype or is expected to be the final code. This is specially important during the vote.

• It's easy to get sidetracked by mail list trolling or well intentioned but over-eager discussion. Take advice on board but make sure your feature doesn't end up being designed by a committee. Don't blame the "PHP core community" for de-railing discussions when the issues of non- code-contributors on the mail list are at fault.

• For every user who wants a backwardly incompatible change to PHP, there is a user who will scream that this will be disasterous to them. As the RFC writer you need to walk the line between these groups. At voting time, other people may see the line in a different place than you do.

• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.

• Don't get side tracked by how long it will take a feature to reach end users. It will reach them eventually. You can always supply an unofficial patch or maybe create a PECL extension for users of current versions of PHP.

• Before initiating a vote on your RFC, make sure the RFC contains enough detail so that the vote is solely on the RFC contents, not on any half-remembered or misinterpretable mail list discussions. Un- (or badly) expressed intentions will only cause you frustration when your RFC is rejected.

• Don't let mail list discussion drag on too long. High levels of discussion can be a symptom that an RFC is contentious. Having an early vote about only the feature's concept can prevent over-investment in an RFC and implementation.

• With long, fragmented discussions, not everyone will read every email. Update the RFC at reg

Truncated by Planet PHP, read more at the original (another 6476 bytes)

Truncated by Planet PHP, read more at the original (another 8113 bytes)

There’s been an issue on Natural Load Testing (our fantastic web application load testing tool) for a while now, we’ve been referring to it as the Double Stacked Graph. Normally the graphs should look like this, kindly sharing the load testing results with the end user, hopefully being both easy to start with and powerful as usage grows.

Unfortunately, what we’ve been seeing occasionally is the dreaded Double Stack: Here you can see that there is two stacked red bars on top of each other. They represent the exact same space in time, but the data is being added to the graph twice for some reason.

Initially I expected that this was an issue with me handling the updates to the graph with ajax poorly. We had an issue with Where’s it Up for a while where results were duplicated. This was the result of asking the server for “new” results every second by passing the server the list of results already obtained. If a request took more than a second to complete, the following request (initiated while the first was outstanding) would be initiated with the same list of previously obtained results, so the server would obligingly return the same “new” results to both requests.

It turned out however that this wasn’t the problem at all, having learned from the Where’s it Up issue I’d coded those ajax requests more carefully. It turns out that the issue had to do with how I was communicating with MySQL. Each time the graph updates it asks for results with a timestamp newer than the newest data it has. The exact query is something like this:

The issue here turns out to be the fact that I'm quoting $minTime. Take a look at these results: mysql> CREATE TABLE `test_decimal` ( -> `job_id` varchar(32) NOT NULL, -> `ts` decimal(13,3) NOT NULL -> ) ENGINE=InnoDB DEFAULT CHARSET=latin1; Query OK, 0 rows affected (0.01 sec) mysql> INSERT INTO `test_decimal` VALUES -> ('9_0209_511673437c4dd', 1360425827.491), -> ('9_0209_511673437c4dd', 1360425828.491), -> ('9_0209_511673437c4dd', 1360425829.491), -> ('9_0209_511673437c4dd', 1360425830.492); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT * from `test_decimal` WHERE `ts` > '1360425827.491' LIMIT 2; +----------------------+----------------+ | job_id | ts | +----------------------+----------------+ | 9_0209_511673437c4dd | 1360425827.491 | | 9_0209_511673437c4dd | 1360425828.491 | +----------------------+----------------+ 2 rows in set (0.00 sec) mysql> SELECT * from `test_decimal` WHERE `ts` > 1360425827.491 LIMIT 2; +----------------------+----------------+ | job_id | ts | +----------------------+----------------+ | 9_0209_511673437c4dd | 1360425828.491 | | 9_0209_511673437c4dd | 1360425829.491 | +----------------------+----------------+ 2 rows in set (0.00 sec)

While using the greater than operator, I’m obtaining results that are equal if the term I’m comparing against is quoted. Without the quotes it performs as expected. This confused me greatly, I’ve been told countless times that I can quote my variables in MySQL to no ill effect, in fact I probably should if I’m not using paramaterized queries for increased security.

The crux of the issue will come down to MySQL’s Type Conversion rules. It must be converting the two values to float to handle the quoted comparison, though I may be at a loss to describe why they’re converted differently. By not quoting the decimal value I allow the comparison to occur between decimal values, and obtain the desired result.

A few people have commented (either here or elsewhere) about MySQL versions. I just re-confirmed t

Truncated by Planet PHP, read more at the original (another 2187 bytes)