There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

Testing is an iterative part of the development process that we carry out to ensure the quality of our code. A large portion of this entails writing test cases and testing each unit of our application using random test data. Actual data for our application comes in when we release it to production, but during the development process we need fake data similar to real data for testing purposes. The popular open source library Faker provides us with the ability to generate different data suitable for a wide range of scenarios.

Faker uses built-in data providers like "Person", "Company", "DateTime" and "UserAgent" to give you randomized output from the data sets you define. Code is included showing how to create the provider in your objects, extending the correct provider and making a request for a property. A real-world example is also included about testing an email marketing engine for address, title, name and content. There's also a little bit added at the end showing how you can increase the randomness of the results returned by "seeding" the Faker engine.

In researching the second edition for the IBM i Programmer's Guide to PHP Jeff and I decided to include a chapter on security since we really didn't talk much about it in the first edition. I'm talking about cross site request forgeries right now and I wanted to make sure that what I was going to suggest would not break the internet in some way. I did some Google searching to see what other people were recommending.

Most of the examples he saw used md5, uniqid and rand to create a randomized hash. He suggests an alternative - a method using the hash_hmac and openssl_random_pseudo_bytes methods to generate a sha256 hash for use in your page's submissions.

Ok, this should have been part one, but irrespective, here's the second installment in zend form mastery with zend config - core form configuration. As the W3c Form spec says, there are 8 attributes applicable to forms.

These attributes, including "action", "name" and "onsubmit", can all be set easily in the XML-based configuration file. He includes an example of the full XML file to show how they all fit together (updated from part 1). You can see an example of the output here and can grab the source for the example from github.

Thanks to FuelPHP's fieldset class, working with forms couldn't be easier. With a few lines of code, you can easily generate and validate a form. Today, we're going to learn how to do just that!

He starts with guiding you through a simple install of the FuelPHP framework and configuring it to connect to a MySQL database. He shows how to set up a model, specify its properties and creating a controller to handle the user interaction. Using the definitions in the model, FuelPHP can automatically generate a form, complete with default options and some validation on the field (things like "required", "valid_url" and "max_length"). There's also code included showing how to edit current posts and listing out the complete post list.

In addition to handling the tedium of generating page and document tables of contents, or maintaining internal links and references, the documentation is now easier to write, as you can simply focus on the content instead of markup and presentation. Don't forget syntax highlighting of PHP, HTML, CSS, and JavaScript in code samples. Based on ReStructured Text, it's also more human readable in a text editor than HTML is, which is likely where you spend most of your time. As an added benefit, Sphinx can output HTML, PDF, and even EPUB formats all from the same source files.

There's also been a style redesign in the latest release (here on github) on the development branch of the framework. They warn of a few "bumps" that you might come across in using it, but they're working hard to take care of those quickly. If you'd like to see the new version, check out the nightly build results.

It supports: browser Settings Detection, campaign Duration, campaign Fields (custom), cross-domain linking and last but not least Ecommerce tracking.

The configuration lets you set the various keys for your Analytics accounts, the domain name for it to live under, browser detection settings and various other settings for campaign configuration and domain setup. You can find the full code on his github account ready to download or clone.

When we talk about "random" numbers, we generally talk about two fundamental properties: Predictability and Bias. Both are closely related, but are subtly different. Predictability in reference to random numbers is the statistical problem of predicting the next value when knowing any number of previous values. Bias on the other hand is the statistical problem of predicting the next value when knowing the distribution of previous values.

He looks at how predictability can effect true random number generation and a common mistake in generation related to bias in the calculation method. He talks about some of the functions PHP includes to work with randomness, but notes that they all have their flaws. He points to the PHP-CryptLib package as a solution (adhering to the guidelines in RFC 4086 for randomness). He includes some sample code of how to use it to generate random numbers, tokens and sets of bytes. You can find the full source over on github.

April 19, 2011 PHPère is happy to show you the first pictures of two premature elePHPant the 6th generation of PHP. As you can see ... ElePHPant the blue, is in great shape and has found its new home very pleasant

These are shots of the first turnouts of this latest batch and the rest will follow in June/July of this year. Those that have already ordered them will be contacted soon and, if you're interested in picking up some of your own, send them an email for complete instructions.

Zend Framework has offerred a code generation component since version 1.8, when we started shipping Zend_Tool. Zend_CodeGenerator largely mimics PHP's ReflectionAPI, but does the opposite: it instead generates code. [...] ZendCodeGenerator in the ZF2 repository is largely ported from Zend Framework 1, but also includes some functionality surrounding namespace usage and imports.

He includes an overview of the different code generation classes available (like PhpBody, PhpFile, PhpProperty, etc) and a bit of code to show you how to create a skeleton class that includes namespace use, class definition and the addition of a "get" method. He also offers some "tips" and "gotchas" to watch out for your first time around like the helpful automagic getter and setter handling.