Douglas Brown has a few helpful hints to help you write your PHP code defensively, protecting your code from malicious attackers.
The phenomenal growth of PHP applications has also led to a mushrooming of increased quantum of malicious activity. It thus becomes imperative that you write secure PHP code to protect your website. Here are some tips for the same. The three most vulnerable aspects of PHP that can become easily accessible to anyone are XSS (Cross Site Scripting), Global Variables and SQL code.
He details what each is and how you can protect your code against the problems they cause. Some example code is included to give you a better idea of the possible solution.
Leonid Mamchenkov has compared Perl versus PHP in this new blog post - specifically how they handle variable scoping.
I've mentioned quite a few times that I am a big fan of Perl programming language. However, most of my programming time these days is spent in PHP. The languages are often similar, with PHP having its roots in Perl, and Perl being such a influence in the world of programming languages. This similarity is often very helpful. However there are a few difference, some of which are obvious and others are not.
His example compares looping (a foreach in both) and how, after the Perl loop the $value variable is no longer accessible. In PHP, however, it's passed back out into the current scope and can be read just like any other variable. While this can be useful, it can also cause headaches when trying to track down elusive bugs.
As a part of a current project Daniel Cousineau came across the need to bridge two languages - PHP and Python - via some serialized variables. This new post on his blog shows how he did it.
So I'm in the planning stages of a project where I'll probably be doing some heavy lifting in Python and serving up the output through PHP. Obviously this will entail transmitting data between Python and PHP and while I haven't had a chance to do performance testing to see if it's worth it to save to a database, the only other option was to serialize the data to a file that PHP could parse quickly. Obviously, the output from serialize() is going to be the fastest way to recieved the data.
As he was working on his own implementation, he came across a currently existing Python library (that adds the serialize support) and but found it lacking for what he needed. He continued on, working up his own customized implementation with all the features he needed. He includes both the Python and PHP code (cut and paste ready) as well as the results from the serialization of different data types.
In a new post today Jani Hartikainen takes a look at one of the things that makes PHP both powerful and unpredictable at times - its variable typing, static versus dynamic.
It seems that PHP has moved a bit towards static typing, and languages like C# seem to be implementing some dynamic features. Are we going towards a "mixed" language with static and dynamic typing? What's the "sweet spot" between completely static (like C++) and completely dynamic typing (like Python)?
He compares the benefits of static and dynamic, and a particular place where PHP falls a bit flat - type hinting in certain situations. He agrees, though, that dynamic typing is "the way to go" since it gives the developer the flexibility they might need for more "typing tricks" in their apps. Oh, and "duck typing"...
David Otton has shared another of his "stupid PHP tricks" on his blog today. This one looks at illegal variable names that don't match the "can't start with a number" rule the manual points out.
A valid variable name starts with a letter or underscore, followed by any number of letters, numbers, or underscores. As a regular expression, it would be expressed thus: '[a-zA-Z_x7f-xff][a-zA-Z0-9_x7f-xff]*'
Technically, you can get around this in two different ways - variable varaibles and the more complex notation with curly braces. He points to the compact function for proof that they're set.
Sebastian Bergmann has a new post today about a feature of the PHPUnit unit testing tool that has the possibility of breaking when objects are introduced - backing up the globals.
It is hard to test code that uses singletons. The same is true for code that uses global variables. Typically, the code you want to test is coupled strongly with a global variable and you cannot control its creation. An additional problem is the fact that one test's change to a global variable might break another test.
You can disable the backup option if you'd like by setting the $backupGlobals option in your test to false. This lets PHPUnit know that you want to leave the globals (and superglobals) alone during the run.
DevShed has posted the latest in their series of tutorials covering the scoping keywords in PHP5 (public, private and protected). In this latest edition they work with private values from a parent class.
In the last article, I explained how to work with a couple of private properties that partially comprised the API of a basic class, which is useful for saving simple strings to a specified text file.
This part builds on this previous example but changes up the subclass (an instance of DataSaver) to use what they call an "accessor" - a function in the parent that returns the private variable/contstant's current value when called.
In a new post to his blog today, Stoyan Stefanov has a proposal to being something PHP users are very used to - superglobals - over to Javascript.
Javascript has implied globals. When you skip the var in var a = 1; and go a = 1;, then a becomes a global variable. Some consider this an error in the language. [...] In PHP on the other hand, variables are local. [...] So how about this: adopt the $GLOBALS convention in your JavaScripts?
His example proposes the creation of a GLOBALS object you can assign properties to that can be used anywhere. This helps to keep the variables you truely want to be global contained, though it doesn't do much except provide a convention.
Michael Kimsalpoints out the posting of the latest part of his "Grails for PHP developers" series to his blog site - Part Five of the series.
I've put up the latest installment in my "Grails for PHP developers". Rather than delve too much more in to Grails head on, I'm taking this installment (and at least the next one) to delve more in to the Groovy language itself. Groovy offers similarities to PHP, but also many differences which can trip you up if you're not careful. I'll try to lay those out as best I can in the next couple of installments.
This new part of the series goes back and puts the spotlight on GRoovy, the base of the Groovy/Grails combo. He talks about working with variables and arrays as containers for multiple pieces of data and some possible gotchas that could come up along the way.
Mike Naberezny has posted a few more articles to the "Rails for PHP Developers" website (based on this book) covering some more of the basics.
There's three new tutorials posted:
Ruby Block Scope - the basics of Ruby block scope, a common point of confusion for PHP developers new to Ruby.
Variable Arguments - an article that shows two common API patterns found in Rails, variable arguments and option hashes, and how to implement them both in PHP.
Regular Expressions in Ruby - a useful reference that maps all of the common PHP regular expression functions to the equivalents in Ruby.
