Up until a few days there was no way to tell PHP from which IP address to submit requests when making connections on a multi-ip server. PHP would automatically pick the 1st external IP and use it deliver external data. To address this limitation, I've added a context option that allows to you to bind an IP from the available local IPs and use it, rather then the default to initiate the connection. [php] $conn = stream_context_create(array('socket'=>array('bindto' => "1.2.3.4:0"))); file_get_contents("http://url", NULL, $conn); [/php] The "socket" wrapper option "bindto" takes a ipv4 or ipv6 address as well as a port, binds the connection to it. Using the port is not necessary in most cases, if you simply wish to bind to a certain IP, specify it followed by ":0" as shown in the example.

Today is the eve of PHP's 10 anniversary, could anyone had guessed that what started as a little Perl script would evolve into a scripting languages powering millions of sites all over the globe. My 1st experience with PHP came around 1998, when the ISP I was using at the time was quite mortified by the load my Perl (CGI) scripts were causing on the server. Their suggestion was to switch to PHP, which supposedly offered performance and would help me not kill server, this was back in the day when PHP 3.0.X was king. As a programmer coming from a C background, PHP was a welcome break from Perl, a language seemingly designed for obfuscation. The thing that impressed me the most about PHP was the online manual, which rivaled many books in clarity and ease of use and a thriving community of users willing to share the knowledge about the language. It was another 2 years before I made my 1st contribution to PHP in a form of the shmop extension that provided quick & simple interface to shared memory for PHP....

A few months ago I proposed a patch that would permit stopping the Zend Parser at a certain point in the script and not having it try to examine any subsequent content. The logic behind this feature was to simplify the process of creating single-script installers, such as the one used by FUDforum. The installer is a single script that at the end of it contains a code archive of the application being installed, which the installation process places into the set locations. The problem with implementing such installer at this point was that the data must be made PHP safe, so no

A few days ago a friend of mine sent me a URL to an online store with a product he found interesting. When I went to the site, aside from the aforementioned product I saw a nice "Hacker Safe" logo, with the date (current date) which was supposed to assure me as a consumer that this site is "safe". Clicking on this logo took me to a page of a security company specializing in "helping sites protect you (the customer) from identity theft and credit card fraud", sounds good, I feel much safer already. Curios about the truth of the site's hacker-safe claims, I decided to do a very basic test for Cross Site Scripting (XSS) by adding a small HTML string in the place of one of the parameter values in the get query. Imagine my surprise when rather then rejecting the clearly bogus value (number was expected, but non-numeric string was supplied), my input and the HTML tags found within were displayed verbatim. This little oversight would allow anyone to inject arbitrary content to be displayed as part of the store’s f...

A few days ago a I noticed an interesting behavior in the session_regenerate_id() function. When it renames the session id it does not remove the old session, leaving it active and potentially usable by a would be hacker. This does not pose a problem if the function is only used during new session create as the means of preventing session fixation, which is the intended use btw. However, it makes it completely useless if used on each session based request to prevent session leakage via HTTP_REFERER and similar, since the previous session id is still usable. It also means that changing the id on “actions” as some scripts to do prevent session theft also is pointless; in fact it doubles the amount of session ids for the same user making it only simpler to assume their identity. Furthermore it means that on every call to the function there is duplication in the number of sessions entries that will hang around until they are considered expired and removed by the garbage collection process. For this reasons, I h...