Doctrine\Common\Cache\CacheProvider performance-aware adapter
In doctrine/common project, with introduction of cache auto-prefix support (called namespaces by Doctrine guys, but it has nothing to do with PHP namespaces), unfortunately there appeared quite serious performance issue. Every single cache call always resulted in 2 additional cache storage calls due to checks for prefix (cache namespace). Quite a big overhead, imagine your memcached instance is called like this. And it just shows that object-oriented programming itself cannot save you from many headaches. Common interface and clean API are just not everything, and it’s soooo easy to get carried away. Anyway, patch has been already provided, but if you’re using older version or you don’t need namespaces support at all, here’s quick workaround.
PHP: Call to undefined method on tr_TR locale
It’s one of weirdest errors in PHP - if not the weirdest - I’ve ever seen. If you set your locale to tr_TR, suddenly some classes or methods names are not available anymore. Really.
Following code:
<?php
setlocale(LC_ALL, 'tr_TR');
class SomeClass {}
$r = new ReflectionClass('SomeClass');
$r->newInstanceArgs(array());
results in Fatal error: Call to undefined method ReflectionClass::newInstanceArgs() error.
After quick research it turned out that it’s actually known bug, yet still not fixed since 2002! See #18556. In short, PHP simply uses internal tolower() function, which is locale-aware, but in Turkish there are some specific rules for I (undotted ı is the lowercase of I, and the dotted İ is the uppercase of i). So if you have class name of method name having upper I (newInstanceArgs, Image, etc), you’re affected.
The only workaround for now seems to be setting LC_CTYPE to some working locale, eg. setlocale(LC_ALL, 'tr_TR'); setlocale(LC_CTYPE, 'en_US');.
Codility sample demo test
I have taken Codility sample demo test at last. I was delaying this memorable moment for a few months, probably for fear that it could somehow turn out Im not that good as I think I am, which is surely the case for most developers. So I did the test and I’m going to take more tests there as it’s quite good fun. And here are my solutions for sample demo test below, both in PHP and Ruby.
PHP date conversions between timezones
In PHP 5.x line dates are handled properly (thanks to Derick Rethans). Even in PHP 5.3 we have loads of nice date/time improvements.
One of nice things is posibility to convert dates between timezones easily.
Regexp: string followed by and preceded by
Regular expressions are full of features (who can learn it all? or read off and understand a few days after it was written?). One of them is possibility to check if desired match is followed or preceded by given pattern.
It works also in PHP.
PDO: grouping results to indexed associative array
Ever wondered how to group database results by first column in PHP? It’s pretty simple with PDO.
PHP: accessing private members of objects of same type
From PHP manual: Objects of the same type will have access to each others private and protected members even though they are not the same instances.
And example from the manual:
XSS via environment variables in PHP
If you ever been at least a bit interested in security of web apps, you must have heard about XSS. You know probably that you need to sanitize any user input, but what isn’t that much clear is that $_SERVER by no means should be trusted entirely.
HTTP_X_FORWARDED_FOR, HTTP_REFERER, any HTTP_USER_*, in some cases even HTTP_HOST, PATH_INFO may be all (usually easily) modified by user. Most of them usually come from an user agent only (browser or whatever, you never know, don’t you?).
Actually $_SESSION should not be trusted sometimes either. If your app is on shared hosting and you store session data in /tmp directory (which is default), other users can get access to it and modify it to whatever they want… or just steal it. Pretty nasty, huh?
Flawed anti-csrf check
Typical anti-csrf (captcha) check looks like that: $_SESSION['csrf_token'] == $_POST['csrf_token']. What’s wrong with this code? If attacker sends POST request directly with empty csrf_token, then it will meet this condition and pass this check easily. So simply remember to verify if value is not-empty, and only then apply actual check.
