osCommerce Blog

Although our development priorities are with finalizing the 3.0 release, a final 2.2 release will also be made prior or simultaneously with the 3.0 release. This will move the 2.2 Milestone 2 release into a final 2.2 release with a small number of known bug fixes, and will close the 2.x release line.

No major features will be introduced into 2.2 as any framework enhancements would break compatibility with add-on contribution packages, and any feature missing is likely to be found with over 4,000 add-ons currently available.

One core framework change that will be introduced with 2.2 is a compatibility layer for servers with register_globals disabled. Currently 2.2 Milestone 2 demands that register_globals be enabled otherwise it refuses to continue working.

The register_globals requirement has always existed since the beginning with The Exchange Project Preview Release 1.0 (March 2000) as at this time PHP 3 was used commonly in conjunction with PHPlib (for session management) and the release of PHP 4.0 was being anticipated with the new Zend engine and native session management support.

Trivia: The Exchange Project Preview Release 1.0 only supported PHP 4 at the time due to the native PHP session management functionality it introduced. It was not until June 2000 that PHP 3 support was added with using PHPlib for its session management functionality, with the release of an “extra pack” for The Exchange Project Preview Release 1.1. Support for PHP 3 at the core level was introduced with The Exchange Project Preview Release 2.0 in December 2000.

The programming standards since The Exchange Project 1.0 to osCommerce 2.2 Milestone 2 have used proper variable scope usage for the $HTTP_GET_VARS ($_GET) and $HTTP_POST_VARS ($_POST) variables. As security and register_globals were non-issues back in the day, the main reason for using correct variable scope usage here were to inform developers which scope the variables were being accessed from. The only variables not used in its correct scope were the session variables which were accessed at the global scope (hello $HTTP_STATE_VARS), and was programmed in mind with register_globals being enabled (which it was by default until PHP 4.2.0 (April 2002)).

Although register_globals needed to be enabled, it was not until June 2002 that it was forced upon in osCommerce 2.2 Milestone 1 (February 2003) with an evil exit() message if it was disabled, as a means to reduce the number of bug reports made with PHP 4.2.0+ installations. This was seen as a temporary measure at the time to have a proper register_globals compatible solution before the 2.2 release was finalized.

The requirement for register_globals was fixed with a proper solution in July 2003 during the development of osCommerce 2.2 Milestone 3. As this was just one of the major incompatibilities to osCommerce 2.2 Milestone 2 it was later decided to completely break compatibility for further improvements and continue onwards to a 3.0 release.

Due to the long development period for 2.2 Milestone 3 / 3.0, it unfortunately kept the register_globals requirement active on the 2.2 Milestone 2 release during this time and will be finally fixed for the final 2.2 release. The fix is covered by a compatibility layer and can only be active on PHP 4.3+ installations. This is to keep compatibility with the add-ons available where advancements to PHP that are used for the compatibility layer are available since 4.3.0. It is not possible to implement a fix for lower PHP versions without breaking compatibility with the available add-ons.

This allows 2.2 to be still used on servers running PHP 3+, PHP 4+, and PHP 5+ with register_globals enabled, and optionally on PHP 4.3+ and PHP 5+ with register_globals disabled. This makes the 2.2 release more interesting even though it is an old release simply because it is a widely used, community supported (4,000+ add-ons!), mature, and secure solution that is a viable alternative to the next generation 3.0 version once it is finalized and released.

The changes for existing installations can be seen here:

http://svn.oscommerce.com/fisheye/changelog/osCommerce/?cs=1583
http://svn.oscommerce.com/fisheye/changelog/osCommerce/?cs=1584

register_globals has lived the past few years with a bad reputation simply due to bad programming or learning from examples at a time where security was not an issue as it is today. The osCommerce 2.2 Milestone 2 release was a big step towards a secure codebase and has not been affected by register_globals vulnerabilities that other PHP solutions have been affected by, even that it requires it to be enabled.

osCommerce 3.0 will work on servers with register_globals enabled or disabled, and disables it at run-time if it is enabled. This is to pass secure coding standards onto developers for the add-ons they develop and make available, and is in preparation for future releases when register_globals is removed from PHP 6.0.