Table of Contents
Anyone who is using the internet and plays with forums - as software developer, webmaster or enthusiast - is most likely aware of what phpBB is: we're talking about the open-source PHP forum platrfom which dominates the web since year 2000, with a ton of skins, themes, plugin, extensions and everything needed to build awesome community-based websites for free.
At the time of writing, the latest phpBB build is 3.1.10, the latest (as we speak) installment of the 3.1.x core stack, which featured an extensive rewrite of the previous engine by adopting - among many other things - the increasingly-popular Symfony web framework: the new core introduced a wide amount of security-related improvements and fixes, being vulnerability the platform's greatest weaknesses - as it can always be expected from a software used by millions of websites.
To cut it short, among the many new features there also are strong restrictions regarding third-party scripts and integrations: you're not supposed to mess with the phpBB source code anymore, as there are APIs available to build virtually any extension to suit most developer needs: anti-spam features, cosmetic changes, authentication/authorization, user customization/profiling and so on. There's also a huge database of already available third-party extensions, featuring more than 1500 contributions if we also count Styles and Language Packs. These extensions work just like WordPress Plugins, with the sole exception that you need to manually unzip and upload them into the /ext/ folder before being able to activate them (no web interface yet).
The Problem
Everything we just said is nothing less than awesome, expecially if you are deploying a brand-new website and just want to plug phpBB in: however, if you already own an existing phpBB customization and want to upgrade it, the security countermeasures enforced by the latest version could cause you some issues. Among the most annoying errors you can stumble upon when upgrading an existing phpBB installation is the following message:
General Error
Illegal use of $_POST. You must use the request class or request_var() to access input data. This error message was generated by deactivated_super_global.
$_POST can be also $_GET, $_FILES, $_COOKIES, $_SESSION, $_REQUEST, $_SERVER, $_ENV or any other PHP superglobal variable.
The explanation for that is very simple: although Superglobals aren't bad by themselves, they just suggest a wrong mindset to the PHP developers, suggesting him that he could execute code in the global scope without problems, avoid variable initialization and so on. Other than that, they contain a lot of info regarding the local system configuration, the logged-in user and so on: the phpBB staff must have thought that disabling superglobals could be a decent safety net against PHP enthusiasts who just want to abuse them in their half-baked, rarely-tested and thus potentially unsafe code. Hence their decision to just remove the pitfall, at least by default.
Nonetheless, such harsh choice causerd a lot of troubles around the web, thus making a lot of PHP developers struggle as we can se by taking a look to the following posts:
- https://area51.phpbb.com/phpBB/viewtopic.php?t=45027 (Official phpBB Developer Forum)
- https://www.phpbb.com/community/viewtopic.php?f=466&t=2284831 (official phpBB Community Forum)
- http://stackoverflow.com/questions/30103342/illegal-use-of-request-you-must-use-the-request-class-or-request-var-to-acc (StackOverflow)
... And so on.
The Solution
Luckily enough, phpBB also provides an option to enable Superglobals back in a matter of seconds. You just have to edit the /phpbb/config/parameters.yml file, which contains most of the phpBB core's default values, and set the core.disable_super_globals key to false.
By doing that, you will enable Superglobals globally and on every script. If you want to enable them for a single script / function only instead, you can use a lighter approach to do it programmatically. This is a quick implementation example:
1 2 3 4 5 6 7 |
// temporarily enable superglobals $request->enable_super_globals(); // TODO: do your stuff here. // disable superglobals again $request->disable_super_globals(); |
Needless to say, this will work only within the current request scope, so all the other PHP scripts will be completely unaffected.
Enabling Superglobals during a phpBB Upgrade
If you've hit the aforementioned enable_super_globals during a phpBB upgrade the programmatic approach won't work well, as it would force you to manually alter the phpBB upgrade script: the best thing you can do is to use the parameters.yml approach and change the default settings, at least temporarily.
Depending on your implementation and the extent of your upgrade, you might have to do that in the parameters.yml file contained in the /install/ folder as well. If that's the case, you will have to disable core.disable_super_globals in these two files:
1 2 |
/phpbb/config/parameters.yml /phpbb/install/update/new/config/parameters.yml |
That's it for now: happy coding!